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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 3 of the control plane of the GPRS Tunnelling Protocol, Version 2 for 
Evolved Packet System interfaces (GTPv2-C). 

In this document, unless otherwise specified the S5 interface refers always to "GTP-based S5" and S8 interface refers 
always to "GTP-based S8" interface. 

GTPv2-C shall be used across the following EPC signalHng interfaces: S3, S4, S5, S8, SIO, Sll and S16. 

GTPv2-C based protocols shall also be used across Sv (3GPP TS 29.280 [15]) and SlOl (3GPP TS 29.276 [14]) 
interfaces. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

GTP-PDU: GTP Protocol Data Unit is either a GTP-C Message or a GTP-U Message. GTP-U Message may be either a 
signalling message across the user plane tunnel, or a G-PDU (see clause 6). 

• Signalling Message: any GTP-PDU (GTP-C or GTP-U) except the G-PDU. 
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• G-PDU: GTP user plane message, which carries the original packet (payload). G-PDU consists of GTP-U 
header and a T-PDU. 

• T-PDU: original packet, for example an IP datagram, from an UE or a network node in an external packet data 
network. A T-PDU is the payload that is tunnelled in the GTP-U tunnel. 

• GTP-C Message: GTP control plane message type of a GTP-PDU. GTP-C message consists of GTP-C 
header, which is followed by zero or more information elements. 

• GTP-U Message: GTP user plane message. The user plane messages are used to carry user data packets, and 
also signalling messages e.g. for path management and error indication. Therefore, GTP-U message consists of 
GTP-U header, which is followed by either a T-PDU, or zero or more information elements. 

GTP Tunnel: FFS (see also subclause 4.1 "GTP Tunnel"). 

Tunnel Endpoint: A tunnel endpoint is identified with a TEID, an IP address and a UDP port number (see subclause 
4.1 "GTP Tunnel"). 

Tunnel Endpoint Identifier (TEID): unambiguously identifies a tunnel endpoint in scope of a path (see subclause 4.1 
"GTP Tunnel"). 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Sl-U 

X2 



Interface between SGW and eNodeB 
Interface between eNodeB s 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AMBR Aggregate Maximum Bit Rate 

APN Access Point Name 

APN-NI Access Point Name Network Identifier 

APN-OI Access Point Name Operator Identifier 

EBI EPS Bearer ID 

eNodeB Evolved Node B 

EPC Evolved Packet Core 

EPS Evolved Packet System 

F-TEID Fully Qualified Tunnel Endpoint Identifier 

G-PDU GTP-U non-signalling PDU 

GPRS General Packet Radio Service 

GTP GPRS Tunnelling Protocol 

GTP-PDU GTP-C PDU or GTP-U PDU 

GTPv2-C GTP version 2, control plane 

GTPv2-U GTP version 2, user plane 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

LBI Linked Bearer identity 

LI Layer 1 

L2 Layer 2 

MEI Mobile Equipment Identity 

MSISDN Mobile Subscriber ISDN Number 

PAA PDN Address Allocation 

PCO Protocol Configuration Options 

PDU Protocol Data Unit 

PDN Packet Data Network or Public Data Network 

PGW PDN Gateway 

PTI Procedure Transaction Id 
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QoS Quality of Service 

RAT Radio Access Type 

RIM RAN Information Management 

SGW Serving Gateway 

TEID Tunnel Endpoint Identifier 

TEID-C Tunnel Endpoint Identifier, control plane 

TEID-U Tunnel Endpoint Identifier, user plane 

TFT Traffic Flow Template 

TLIV Type Length Instance Value 

UDP User Datagram Protocol 

ULI User Location Information 
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4 General 

4.1 GTP Tunnel 

GTP tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different 
communication flows. 

A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The receiving end side of a 
GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between 
tunnel endpoints using GTP-C or Sl-MME messages. 

The criteria defining when the same or different GTP tunnels shall be used between the two nodes differs between the 
control and the user plane, and also between interfaces. 

For the control plane, for each end-point of a GTP-C tunnel: 

The TEID-C shall be unique per PDN-Connection on GTP based S5 and S8 interfaces. The same tunnel shall be 
shared for the control messages related to all bearers associated to the PDN-Connection. A TEID-C on the S5/S8 
interface shall be released after all its associated EPS bearers are deleted. 

There shall be only one pair of TEID-Cs per UE on each of the S3, S 10 and the S 16 interfaces. The same tunnel 
shall be shared for the control messages related to the same UE operation. A TEID-C on the S3/S10/S16 
interface shall be released after its associated UE context is removed or the UE is detached. 

There shall be only one pair of TEID-C per UE over the S 11 and the S4 interfaces. The same tunnel shall be 
shared for the control messages related to the same UE operation. A TEID-C on the S 1 1/S4 interface shall be 
released after all its associated EPS bearers are deleted. 

For GTP-U, a TEID-U is used according to 3GPP TS 29.281 [13]. 

NOTE: GTP-U is based on GTP version 1 (GTPvl). 

4.2 Protocol stack 
4.2.0 General 

The protocol stack for GTPv2 shall be as depicted in Figure 4.2.0-1. 
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GTP 






GTP 






UDP 


UDP 






IP 


IP 




L2 


L2 




LI 


LI 







GTPv2 entity 



GTPv2 entity 



GTPv2 based 
interface 



Figure 4.2.0-1 : GTPv2 stack 

The GTPv2 headers are specified in the respective clauses of this specification. 

The source and destination IP addresses and UDP ports used for each GTP-C message depend on the role that the 
message plays in a message exchange. A message can be an Initial message, or a Triggered message, or a Triggered 
Reply message to Triggered message. An Initial message is sent to a peer GTP entity with a sequence number chosen 
by the sending entity (see subclause 7.6). A Triggered message is sent in response to an Initial message. Triggered 
Reply message may be sent in response to a Triggered message. See subclause 7.6 for the sequence number usage. 

Typically, a Request message is an Initial message, but a Request message may be a Triggered messages in certain 
procedures where they are triggered by an Initial Command message. See subclause 4.2.5 for classification of the Initial 
messages and their possible Triggered messages, as well as cases where there are Triggered Reply messages to the 
Triggered messages. 

Piggybacking is an optional feature. If the feature is supported, then the piggybacking of the initial messages on 
triggered response messages for EUTRAN Initial Attach and UE-requested PDN Connectivity procedures shall be 
implemented as per Annex F of 3GPP TS 23.401 [3].When piggybacking is used, a common IP header and a common 
UDP header shall be used for the triggered response message and the piggybacked initial message as depicted in Figure 
4.2.0-2. Immediately following the triggered response message is the piggybacked initial message, following which no 
additional information shall be present. The subclause 5.5 specifies the usage of piggybacking-specific fields in the 
GTP-C header. 



IP header 


UDP header 


Triggered response message 
(P=1) 


Piggybacked initial message 
(P=0) 



Figure 4.2.0-2: Packet Format for the Piggybacking of messages 

4.2.1 UDP header and port numbers 
4.2.1.0 General 

A User Datagram Protocol (UDP) compliant with IETF RFC 768 [7] shall be used. 
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4.2.1.1 Initial Messages 

The UDP Destination Port number for GTPv2 Initial messages shall be 2123. It is the registered port number for GTP- 
C. 

The UDP Source Port for a GTPv2 Initial message is a locally allocated port number at the sending GTP entity. 

If GTPv2 and GTP' v2 modules are using the same IP address for sending messages, the implementation shall ensure 
that while some source port number is used by GTPv2 messages, the same source port number shall not be used by 
GTP' v2 messages. Otherwise, the IP interface may have difficulty to delivering a response message to the right 
protocol entity. 

4.2.1.2 Triggered Messages 

The UDP Destination Port value of a GTPv2 Triggered message and for a Triggered Reply message shall be the value 
of the UDP Source Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the 
SGSN pool scenario. 

The UDP Source Port of a GTPv2 Triggered message and for a Triggered Reply message shall be the value from the 
UDP Destination Port of the corresponding message to which this GTPv2 entity is replying, except in the case of the 
SGSN pool scenario. 

In the SGSN pool scenario, if the Identification Request or the Context Request messages have been forwarded by 
another SGSN in the pool, the UDP Destination Port for the Identification Response or the Context Response message 
shall be determined in the following way. The value from the information element "UDP Source Port Number", which 
was sent in the corresponding forwarded request, shall be copied into the UDP Destination Port field. The UDP Source 
Port for the Identification Response or the Context Response message may be a locally allocated port number at the 
sending GTP entity. 

4.2.1.3 Piggybacked Messages 

A piggybacked initial message is carried as a concatenation after a triggered response message and they share a 
common UDP header (see Figure 4.2.0-2). 

The UDP Destination port for the IP packet containing both the triggered response message and the piggybacked initial 
message shall be the same as the port number used for the triggered response message. 

The UDP Source port for the IP packet containing both the triggered response message and the piggybacked initial 
message shall be the same as the port number used for the triggered response message. 

4.2.2 IP header and IP addresses 

4.2.2.1 Initial Messages 

The IP Destination Address of a GTPv2 Initial message shall be an IP address of the destination GTPv2 entity. 

The IP Source Address of a GTPv2 Initial message shall be an IP address of the source GTPv2 entity from which the 
Initial message is originating. 

4.2.2.2 Triggered Messages 

The IP Destination Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the 
IP Source Address of the message to which this GTPv2 entity is replying, except in the case of the SGSN pool scenario. 

The IP Source Address of a GTPv2 Triggered message and for a Triggered Reply message shall be copied from the IP 
destination address of the message to which this GTPv2 entity is replying, except in the case of SGSN pool scenario. 

In the SGSN pool scenario, if the Identification Request or the Context Request messages have been forwarded by 
another SGSN in the pool, the IP Source address for the Identification Response or the Context Response messages 
shall be locally allocated by the sending GTP entity. The IP Destination Address for the Identification Response or 
Context Response messages shall be determined in the following way. The value from the information element 
"Address for Control Plane", which was sent in the corresponding Identification Request message; or the value from the 
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information element "S3/S16/S10 Address and TEID for Control Plane", which was sent in the corresponding Context 
Request message, shall be copied into the IP Destination Address field. 

4.2.2.3 Piggybacked Messages 

A piggybacked initial message is carried as a concatenation after a triggered response message and they share a 
common IP header (see Figure 4.2.0-2). 

The IP Source Address for the IP packet containing both the triggered response message and the piggybacked initial 
message shall be the same as the IP Address used for the triggered response message. 

The IP Destination Address for the IP packet containing both the triggered response message and the piggybacked 
initial message shall be the same as the IP Address used for the triggered response message. 

4.2.3 Layer 2 

Typically Ethernet should be used as a Layer 2 protocol, but operators may use any other technology. 

4.2.4 Layer 1 

Operators may use any appropriate Layer 1 technology. 

4.2.5 Messages with GTPv2 defined replies: Classification of Initial and 
Triggered Messages 

NOTE: Other clauses of this specification and Stage 2 documents define in detail when a reply message is 
expected in an end-to-end procedure. Reply messages are triggered messages. 

The expected reply to a Request message is a Triggered message and the reply has the same message name as the 
Request but with "Response" replacing "Request". If a Request message is a reply to a Command message, then the 
Request message is a Triggered message; otherwise the Request message is an Initial message. Responses do not have 
replies except when a "Context Acknowledge" is required as a reply to "Context Response" message as specified in 
relevant Stage 2 procedures. Context Acknowledge is always triggered message and does not have a reply. 

A message whose name ends in "Command" is always an initial message. If a "Command" message fails, the name of 
the reply message is constructed by replacing "Command" with "Failure Indication". Apart from "Downlink Data 
Notification Failure Indication" message, a "Failure Indication" is a Triggered message. The "Failure Indication" 
message does not have a reply. If a "Command" message is successful, its reply will be a Request as specified in 
relevant Stage 2 procedures. 

A message whose name ends in "Notification" is always an Initial message. The expected Triggered message in reply 
has the same message name but with "Acknowledge" replacing "Notification", except for the case of the message 
"Downlink Data Notification" which has the reply "Downlink Data Notification Acknowledge". An "Acknowledge" 
message does not have a reply. 

CS Paging Indication, Stop Paging Indication, RAN Information Relay, Configuration Transfer Tunnel, Trace Session 
Activation, Trace Session Deactivation, and Downlink Data Notification Failure Indication messages are Initial 
messages that do not have a reply. 

A Version Not Supported Indication message is a Triggered message. 

4.3 Transmission Order and Bit Definitions 

The messages in this document shall be transmitted in network octet order starting with octet 1 with the Most 
Significant Bit sent first. 

The most significant bit of an octet in a GTP message is bit 8. If a value in a GTP message spans several octets and 
nothing else is stated, the most significant bit is bit 8 of the octet with the lowest number. 
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GTP Header for Control Plane 



5.1 



General format 



Control Plane GTP uses a variable length header. Control Plane GTP header length shall be a multiple of 4 octets. 
Figure 5.1-1 illustrates the format of the GTPv2-C Header. 



Octets 
1 
2 
3 

4 

m to 

k(m+3) 

n to (n+2) 

(n+3) 



Bits 

5 4 



Version 



T I Spare | Spare | Spare 



Message Type 



Message Length (r' Octet) 



wr, 



Message Length (2™ Octet) 



If T flag is set to 1 , then TEID shall be placed into octets 5- 
8. Otherwise, TEID field is not present at all. 



Sequence Number 



Spare 



Where: 



Figure 5.1-1 : General format of GTPv2 Header for Control Plane 

if T = 0, TEID field is not present, k = 0, m = and n = 5; 

if T = 1, TEID field is present, k = 1, m = 5 and n = 9. 

The usage of GTPv2-C header across the EPC specific interfaces is defined in the subclause 5.5 "Usage of the GTPv2-C 
Header". Octet 1 bits shall be coded as follows: 

Bits 6-8 represent the Version field. 

Bit 5 represents the Piggybacking flag (P). 

Bit 4 represents the TEID flag (T). 

Bits 3-1 are spare, the sender shall set them to "0" and the receiving entity shall ignore them. 

5.2 Control Plane GTP Extension Header 

The legacy Extension Header mechanism is not used for the GTP version 2 control plane (GTPv2-C). Future extensions 
will be implemented by adding Information Elements in the message body if new parameters are needed. 



5.3 GTP-C header for Echo and Version Not Supported 
messages 

The GTPv2-C message header for the Echo Request, Echo Response and Version Not Supported Indication messages 
shall not contain the TEID field, but shall contain the Sequence Number fields, followed by one spare octet as depicted 
in figure 5.3-1. The spare bits shall be set to zero by the sender and ignored by the receiver. 



Octets 
1 
2 
3 
4 
5 
6 
7 



Figure 5.3-1 : The format of Echo and Version Not Supported messages Header 



8 7 


Bits 

6 5 4 


3 2 1 


Version | P | T=0 


Spare Spare Spare 


Message Type 




Message Length (1^' 


Octet) 




Message Length (2™ 


Octet) 




Sequence Number (I** 


' Octet) 


Sequence Number (2™ Octet) 




Sequence Number (3' 


^ Octet) 


Spare 
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5.4 EPC specific GTP-C header 



Apart from the Echo Request, Echo Response and Version Not Supported Indication messages, the GTP-C message 
header shall contain the TEID and Sequence Number fields followed by one spare octet. A typical GTP-C header is 
depicted in figure 5.4-1. The spare bits shall be set to zero by the sender and ignored by the receiver. 



Octets 

1 

2 

3 

4 

5 

6 

7 

8 

9 
10 
11 
12 



Bits 

5 4 



Version 



T=1 I Spare | Spare | Spare 



Message Type 



Message Length (r' Octet) 



Message Length (2"° Octet) 



Tunnel Endpoint Identifier (1 Octet) 



Tunnel Endpoint Identifier (2™ Octet) 



Tunnel Endpoint Identifier (S'" Octet) 



Tunnel Endpoint Identifier (4 Octet) 



Sequence Number (1"' Octet) 



JW, 



Sequence Number (2"° Octet) 



Sequence Number (3 Octet) 



Spare 



Figure 5.4-1 : The format of EPC specific GTPv2 Control Plane message Header 

5.5 Usage of the GTPv2-C Header 

The format of the GTPv2-C header is specified in subclause 5.1 "General format". The usage of the GTP-C header 
across e.g. SlOl (3GPP TS 29.276 [14]) and Sv (3GPP TS 29.280 [15]) interfaces are defined in their respective 
specifications. 

The usage of the GTPv2-C header for EPC specific interfaces shall be as defined below. 

The first octet of the header shall be used is the following way: 

Bits 8 to 6, which represent the GTP-C version, shall be set to decimal 2 ("010"). 

Bit 5 represents a "P" flag. If the "P" flag is set to "0", no piggybacked message shall be present. If the "P" flag 
is set to "1", then another GTPv2-C message with its own header and body shall be present at the end of the 
current message. 

When present, a piggybacked message shall have its "P" flag set to "0" in its own header. If Create Session 
Response message (as part of EUTRAN initial attach or UE-requested PDN connectivity procedure) has the "P" 
flag set to "1", then a Create Bearer Request message shall be present as the piggybacked message. As a 
response to the Create Bearer Request message, if the Create Bearer Response has the "P" flag set to "1", then a 
Modify Bearer Request (as part of EUTRAN initial attach or UE-requested PDN connectivity procedure) shall 
be present as the piggybacked message. A Create Bearer Response with "P" flag set to "1" shall not be sent 
unless a Create Session Response with "P" flag set to "1" has been received for the same procedure. Apart from 
Create Session Response and Create Bearer Response messages, all the EPC specific messages shall have the 
"P" flag set to "0". 

Bit 4 represents a "T" flag, which indicates if TEID field is present in the GTP-C header or not. If the "T" flag is 
set to 0, then the TEID field shall not be present in the GTP-C header. If the "T" flag is set to 1, then the TEID 
field shall immediately follow the Length field, in octets 5 to 8. Apart from the Echo Request, Echo Response 
and Version Not Supported Indication messages, in all EPC specific messages the value of the "T" flag shall be 
set to "1". 

Bit 3 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it. 

Bit 2 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it. 

Bit 1 is a spare bit. The sending entity shall set it to "0" and the receiving entity shall ignore it. 

The usage of the fields in octets 2 - n of the header shall be as specified below. 
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Octet 2 represents the Message type field, which shall be set to the unique value for each type of control plane 
message. Message type values are specified in Table 6.1-1 "Message types for GTPv2". 

Octets 3 to 4 represent the Length field. This field shall indicate the length of the message in octets excluding the 
mandatory part of the GTP-C header (the first 4 octets). The TEID (if present) and the Sequence Number shall 
be included in the length count. The format of the Length field is specified in subclause 8.2 "Information 
Element Format". 

A piggybacked initial message and the preceeding triggered response message present in the common IP/UDP 
packet shall have their own length and sequence number in their respective GTP-C headers. The overall length 
of the IP/UDP packet shall indicate the total length of the two GTP-C messages. 

For EPC specific interfaces, T=l, and therefore octets 5 to 8 represent the Tunnel Endpoint Identifier (TEID) 
field. This field shall unambiguously identify a tunnel endpoint in the receiving GTP-C entity. The Tunnel 
Endpoint Identifier is set by the sending entity to the value provided by the corresponding receiving entity. When 
a peer's TEID is not available, as in the following cases, the TEID field shall be present in a GTPv2-C header, 
but its value shall be set to "0": 

Create Session Request message on S5/S8 

Create Session Request message on S4/S 11 , if for a given UE, the SGSN/MME has not yet obtained the 
Control TEID of the SGW. 

Create Indirect Data Forwarding Tunnel Request message on S4/S 11 , if the SGW selected by the MME/S4- 
SGSN for indirect data forwarding is different from the SGW used as anchor. 

Identification Request/Response messages. 

Forward Relocation Request message. 

Context Request message. 

Relocation Cancel Request message except for the case where the old SGSN/MME has already been 
assigned the Tunnel Endpoint Identifier Control Plane of the new SGSN/MME. 

Delete PDN Connection Set Request/Response messages. 

Configuration Transfer Tunnel message. 

RAN Information Relay message. 

If a node receives a message for which it has no context, it shall respond with "Context not found" Cause in 
the corresponding response message to the sender. The TEID used in the GTPv2-C header in the response 
message shall be set to zero. 

NOTE: The Change Notification Request/Response messages are also sent on the TEID zero. These messages are 
not listed in the procedures above because the peer"s node TEID is available. 

Octets 9 to 1 1 represent GTP Sequence Number field. 

5.6 Format of the GTPv2-C Message 

The GTP-C header may be followed by subsequent information elements dependent on the type of control plane 
message. 



Octets 

1 to m 
m+1 to n 


Bits 
8 7 6 5 4 3 2 


1 




GTP-C header 




Zero or more Information Element(s) 









Figure 5.6-1 : GTP-C Header followed by subsequent Information Elements 
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6 GTP-C Message Types and Message Formats 

A GTP-C message is sent across a GTP control plane tunnel. In a message, the GTP-C header is followed by zero or 
more information elements. The GTP-C messages are used for the control plane path management, for the control plane 
tunnel management and for mobility management. 

A T-PDU is an original packet, for example an IP datagram, from an UE, or from a network node in an external packet 
data network. 

6.1 Message Format and Type values 

GTP defines a set of messages between two associated EPC network elements. The messages to be used shall be as 
defined in Table 6.1-1. 
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Table 6.1-1 : Message types for GTPv2 



Message Type 
value (Decimal) 


Message 


Reference 


GTP-C 


GTP-U 





Reserved 








1 


Echo Request 




X 


X 


2 


Echo Response 




X 


X 


3 


Version Not Supported Indication 




X 




4 to 24 


Reserved for SI 01 interface 


TS 29.276 [14] 






25 to 31 


Reserved for Sv interface 


TS 29.280 [151 








SGSN/MME to PGW (S4/S1 1 , S5/S8) 








32 


Create Session Request 




X 




33 


Create Session Response 




X 




34 


IVIodify Bearer Request 




X 




35 


IVIodify Bearer Response 




X 




36 


Delete Session Request 




X 




37 


Delete Session Response 




X 






SGSN to PGW (S4, S5/S8) 








38 


Change Notification Request 




X 




39 


Change Notification Response 




X 




40 to 63 


For future use 










Messages without explicit response 








64 


Modify Bearer Command 
(MME/SGSN to PGW - SI 1/S4, S5/S8) 




X 




65 


Modify Bearer Failure Indication 
(PGW to MME/SGSN - S5/S8, SI 1/S4) 




X 




66 


Delete Bearer Command 
(MME/SGSN to PGW - SI 1/S4, S5/S8) 




X 




67 


Delete Bearer Failure Indication 

(PGW to MME/SGSN - S5/S8, SI 1/S4)) 




X 




68 


Bearer Resource Command 
(MME/SGSN to PGW - SI 1/S4, S5/S8) 




X 




69 


Bearer Resource Failure Indication 
(PGW to MME/SGSN - S5/S8, SI 1/S4) 




X 




70 


Downlink Data Notification Failure Indication 
(SGSN/MME to SGW - S4/S1 1 ) 




X 




71 


Trace Session Activation 




X 




72 


Trace Session Deactivation 




X 




73 


Stop Paging Indication 




X 




74 to 94 


For future use 










PGW to SGSN/MME (S5/S8, S4/S11) 








95 


Create Bearer Request 




X 




96 


Create Bearer Response 




X 




97 


Update Bearer Request 




X 




98 


Update Bearer Response 




X 




99 


Delete Bearer Request 




X 




100 


Delete Bearer Response 




X 






PGW to MME, MME to PGW, SGW to PGW, SGW to MME 
(S5/S8, S11) 








101 


Delete PDN Connection Set Request 




X 




102 


Delete PDN Connection Set Response 




X 




103 to 127 


For future use 










MME to MME, SGSN to MME, MME to SGSN, SGSN to 
SGSN(S3/S10/S16) 








128 


Identification Request 




X 




129 


Identification Response 




X 




130 


Context Request 




X 




131 


Context Response 




X 




132 


Context Acknowledge 




X 




133 


Forward Relocation Request 




X 




134 


Forward Relocation Response 




X 




135 


Forward Relocation Complete Notification 




X 




136 


Forward Relocation Complete Acknowledge 




X 




137 


Forward Access Context Notification 




X 




138 


Forward Access Context Acknowledge 




X 




139 


Relocation Cancel Request 




X 
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Message Type 
value (Decimal) 


Message 


Reference 


GTP-C 


GTP-U 


140 


Relocation Cancel Response 




X 




141 


Configuration Transfer Tunnel 




X 




142 to 148 


For future use 








152 


RAN Information Relay 




X 






SGSN to MME, MME to SGSN (S3) 








149 


Detach Notification 




X 




150 


Detach Acknowledge 




X 




151 


CS Paging Indication 




X 




152 


See above 








153 


Alert MME Notification 




X 




154 


Alert MME Acknowledge 




X 




155 


UE Activity Notification 




X 




156 


UE Activity Acknowledge 




X 




157 to 159 


For future use 










MME to SGW, SGSN to MME (S11/S3) 
SGSN to SGSN (SI 6) 








162 


Suspend Notification 




X 




163 


Suspend Acknowledge 




X 






SGSN/MME to SGW (S4/S11) 








160 


Create Forwarding Tunnel Request 




X 




161 


Create Forwarding Tunnel Response 




X 




162 


See above 




X 




163 


See above 




X 




164 


Resume Notification 




X 




165 


Resume Acknowledge 




X 




166 


Create Indirect Data Forwarding Tunnel Request 




X 




167 


Create Indirect Data Forwarding Tunnel Response 




X 




168 


Delete Indirect Data Forwarding Tunnel Request 




X 




169 


Delete Indirect Data Forwarding Tunnel Response 




X 




170 


Release Access Bearers Request 




X 




171 


Release Access Bearers Response 




X 




172 to 175 


For future use 










SGW to SGSN/MME (S4/S11) 








176 


Downlink Data Notification 




X 




177 


Downlink Data Notification Acknowledge 




X 






SGW to SGSN (S4) 








178 


Reserved 








179 to 199 


For future use 










SGW to PGW, PGW to SGW (S5/S8) 








200 


Update PDN Connection Set Request 




X 




201 


Update PDN Connection Set Response 




X 






Other 








202 to 255 


For future use 









6.1 .1 Presence requirements of Information Elements 

There are four different presence requirements (Mandatory, Conditional, Optional, or Conditional-Optional) for an IE 
within a given GTP-PDU: 

Mandatory means that the IE shall be included by the sending side, and that the receiver diagnoses a "Mandatory 
IE missing" error, when detecting that the IE is not present. A response including a "Mandatory IE missing" 
cause, shall include the type of the missing IE. 

Conditional means: 

that the IE shall be included by sending entity if the conditions specified in the relevant protocol specification 
are met; 

the receiver shall check the conditions as specified in the corresponding message type description, based on 
the parameter combination in the message and/or on the state of the receiving node, to infer if a conditional 
IE shall be expected. Only if a receiver has sufficient information the following applies. A conditional IE, 
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which is absolutely necessary for the receiving entity to complete the procedure, is missing, then the receiver 
shall abort the procedure. 

Conditional-Optional means: 

that the IE shall be included by the up-to-date sending entity, if the conditions specified in the relevant 
protocol specification are met. An entity, which is at an earlier version of the protocol and therefore is not up- 
to-date, obviously cannot send such new IE. 

the receiver need not check the presence of the IE in the message. If the receiver checks the presence of the 
Conditional-Optional IE, then the lE's absence shall not trigger any of the error handling procedures. The 
handling of an absence or erroneous such lEs shall be treated as Optional lEs as specified in subclause 7.7 
"Error Handling". 

Optional means: 

that the IE shall be included as a service option. Therefore, the IE may be included or not in a message. The 
handling of an absent optional IE, or an erroneous optional IE is specified in subclause 7.7 "Error Handling". 

For conditional lEs, the clause describing the GTP-PDU explicitly defines the conditions under which the inclusion of 
each IE becomes mandatory or optional for that particular GTP-PDU. These conditions shall be defined so that the 
presence of a conditional IE only becomes mandatory if it is critical for the receiving entity. The definition might 
reference other protocol specifications for final terms used as part of the condition. 

For grouped lEs, the presence requirement of the embedded IE shall follow the rules: 

The grouped IE is Mandatory: if the embedded IE in the grouped IE is Mandatory, this embedded IE is viewed 
as Mandatory IE by the receiver. If the embedded IE in the grouped IE is Conditional, this embedded IE is 
viewed as Conditional IE by the receiver. If the embedded IE in the grouped IE is Optional, this embedded IE is 
viewed as Optional IE by the receiver. 

The grouped IE is Conditional: if the embedded IE in the grouped IE is Mandatory or Conditional, this 
embedded IE is viewed as Conditional IE by the receiver. If the embedded IE in the grouped IE is Optional, this 
embedded IE is viewed as Optional IE by the receiver. 

The grouped IE is Optional: the embedded IE in the grouped IE is viewed as Optional IE by the receiver. 

Only the Cause information element shall be included in the response if the Cause contains a value that indicates that 
the request is not accepted. Optionally, the Protocol Configuration Options and the Recovery information element may 
be included. Failure Indication type messages do not have "Accept" types of cause values, therefore the proceeding 
rules do not apply. For Failure Indication type of messages, some of the Mandatory information elements may not be 
included if they are not available. 

6.1.2 Grouped Information Elements 

Information elements can contain other lEs. This type of IE is called "Grouped lEs". 

Grouped lEs have a length value in the TLIV encoding, which includes the added length of all the embedded lEs. 
Overall coding of a grouped information element with 4 octets long IE header is defined in subclause 8.2 "Information 
Element Format". Each information element within a grouped IE also shall also contain 4 octets long IE header. 

Grouped lEs are not marked by any flag or limited to a specific range of IE type values. The clause describing an IE in 
this specification shall explicitly state if it is grouped. 

NOTE 1: Each entry into each Grouped IE creates a new scope level. Exit from the grouped IE closes the scope 
level. The GTPv2 message level is the top most scope. This is analogous to the local scope of a 
subroutine/function. 

If more than one grouped information elements of the same type, but for a different purpose are sent with a message, 
these lEs shall have different Instance values. 

If more than one grouped information elements of the same type and for the same purpose are sent with a message, 
these lEs shall have exactly the same Instance value to represent a list. 
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NOTE 2: For instance, all "Bearer Contexts Modified" lEs of the type "Bearer Context" in a "Modify Bearer 

Response" message shall have the Instance value of 0, while all "Bearer Contexts Marked for Removal" 
IBs of the type "Bearer Context" in the same message shall have the Instance value of 1 . 

6.1 .3 Information Element instance 

Every GTPv2 message and grouped IE within a message in this specification has a column documenting the instance 
value of each IE. 

When a GTPv2 message is encoded for use the instance value of each included IE is encoded in the Instance field of the 
IE for the message scope. See clause 7 and subclause 8.2 for details of that encoding. 

An Information Element in an encoded GTPv2 message or encoded grouped IE is identified by the pair of IE Type and 
Instance values and described by a specific row in the corresponding tables in subclauses of 7 in the present document. 

If several Information Elements with the same Type and Instance values are included in an encoded GTPv2 message, 
they represent a list for the corresponding IE name and row identified in the message grammar in subclauses of clause 
7. 

If several Information Elements with the same Type and Instance values are included in an encoded grouped IE, they 
represent a list for the corresponding IE name and row identified in the grouped IE grammar in subclauses of clause 7. 

In tables in this document the instance value for "Private Extension" is marked as VS (Vendor Specific). While an 
instance value must be encoded by the sender the value can be Vendor and even Private Extension specific. 

The same IE name might be used in different messages (on the top level or within grouped lEs) in this specification. 
The instance value and name of an IE is only meaningful within the scope of the message definition . The combination 
of Type value and Instance value uniquely identifies a specific row in a message description table. 

6.2 Message Granularity 

The GTPv2-C messages shall be sent per UE on the S3, SIO and S16 interfaces. 

The GTPv2-C messages shall be sent per PDN-Connection on the S4, SI 1, S5 and S8 interfaces apart from the 
following exclusion. 

The following GTPv2-C messages are sent per UE on the S4 and Sll interfaces: 

Downlink Data Notification / Acknowledge / Failure Indication. 

Stop Paging Indication. 

Delete Indirect Data Forwarding Tunnel Request/Response. 

Delete Session Request during TAU/RAU/Handover/SRNS Relocation Cancel Using S4/Inter RAT handover 
Cancel procedure with SGW change/Sl based handover cancel procedure with SGW change. 

Release Access Bearers Request/Response. 

Create Indirect Data Forwarding Tunnel Request/Response. 

Trace Session Activation. 

- Trace Session Deactivation. 

Create Forwarding Tunnel Request/Response. 
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7 GTP-C messages 

7.1 Path Management Messages 

7.1.0 General 

Three path management messages are specified for GTP-C: Echo Request, Echo Response and Version Not Supported 
Indication. 

The usage of Echo Request / Response procedure is specified in 3GPP TS 23.007 [17]. 

7.1.1 Echo Request 

Table 7.1.1-1 specifies the information elements included in the Echo Request message. 

The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17]) 

The optional Private Extension contains vendor or operator specific information. 

Table 7.1.1-1: Information Elements in Echo Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Recovery 


M 




Recovery 





Private Extension 







Private Extension 


vs 



7.1.2 Echo Response 

Table 7.1.2-1 specifies the information elements included in the Echo Response message. 

The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17]) 

The optional Private Extension contains vendor or operator specific information. 

Possible Cause values are: 

"System failure" 

"Mandatory IE incorrect" 

"Mandatory IE missing" 

"Invalid Message format" 

Table 7.1.2-1: Information Elements in Echo Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Recovery 


M 




Recovery 





Cause 





IE may be included if recovery IE in the Echo Request or 
the message itself is malformed. 


Cause 





Private Extension 







Private Extension 


VS 



NOTE: If the Cause value is not a successful value this does not indicate the node sending the Echo Response is 
unable to accept GTPv2 messages. 

7.1 .3 Version Not Supported Indication 

This message contains only the GTPv2 header and indicates the latest GTP version that the sending entity supports. 
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7.2 Tunnel Management Messages 



A node shall include the Recovery information element if it is in contact with the peer for the first time or the node has 
restarted recently and the new Restart Counter value has not yet been indicated to the peer. The peer receiving the 
Recovery information element shall handle it as when an Echo Response message is received but shall consider the rest 
of the message in accordance with the message semantics and parameters. 

7.2.1 Create Session Request 

The direction of this message shall be from MME/S4-SGSN to SOW and from SGW to PGW (see Table 6.1-1). 

The Create Session Request message shall be sent on the Sll interface by the MME to the SGW, and on the S5/S8 
interface by the SGW to the PGW as part of the procedures: 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 

The message shall also be sent on S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the SGW to the 
PGW as part of the procedures: 

- PDP Context Activation 

The message shall also be sent on the Sll interface by the MME to the SGW as part of the procedures: 
Tracking Area Update procedure with Serving GW change 
Sl/X2-based handover with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

- 3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure 

- Gn/Gp SGSN to MME Tracking Area Update procedure 

and on the S4 interface by the SGSN to the SGW as part of the procedures: 
Routing Area Update with MME interaction and with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 
Serving RNS relocation 

Combined hard handover and SRNS relocation 

- Combined Cell / URA update and SRNS relocation 

Enhanced serving RNS relocation with SGW relocation 

If the new Create Session Request message is received with TEID in the header for an existing active PDN connection 
context, this Create Session Request message shall be treated as a request for a new session. The existing PDN 
connection context should be deleted locally, before a new session is created. 
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Table 7.2.1-1 : Information Elements in a Create Session Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





MSISDN 


C 


For an E-UTRAN Initial Attach the IE shall be included 

when used on the S1 1 Interface, if provided in the 

subscription data from the HSS. 

For a PDP Context Activation procedure the IE shall be 

included when used on the S4 interface, if provided in the 

subscription data from the HSS. 

The IE shall be included for the case of a UE Requested 

PDN Connectivity, it shall be included if the IVIME has it 

stored for that UE. 

It shall be included when used on the S5/S8 interfaces if 

provided by the MME/SGSN. 


MSISDN 





ME Identity (MEI) 


C 


The MME shall include the IVIE Identity (IVIEI) IE, if it is 
available. 


MEI 





User Location 
Information (ULI) 


C 


This IE shall be included for E-UTRAN Initial Attach and 
UE-requested PDN Connectivity procedures. It shall 
include ECGI&TAI. The MME/SGSN shall also include It 
forTAU/RAU/X2-Handover/Enhanced SRNS Relocation 
procedure if the PGW has requested location information 
change reporting and MME/SGSN support location 
information change reporting. The SGW shall include this 
IE on S5/S8 if it receives the ULI from MME/SGSN. 


ULI 





CO 


This IE shall also be included on the S4 and S5/S8 
interfaces for PDP Context Activation procedure. It shall 
include either the CGI or SAI or RAI. 


Serving Networl< 


c 


This IE shall be included on S4/S11 and S5/S8 interfaces 
for an E-UTRAN initial attach, a PDP Context Activation 
and for a UE requested PDN connectivity. 


Serving Network 





CO 


This IE shall be included on S4/S1 1 for 
RAU/TAU/Handover with SGW relocation procedures. 


RAT Type 


M 




RAT Type 





Indication Flags 


c 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags are: 

S5/S8 Protocol Type: This flag shall be used on 
the S1 1/S4 interfaces and set according to the 
protocol chosen to be used on the S5/S8 
interfaces. 

Dual Address Bearer Flag: This flag shall be set to 
1 when the UE requests a PDN type IPv4v6 and all 
SGSNs which the UE may be handed over to 
support dual addressing. This shall be determined 
based on node pre-configuration by the operator. 

Handover Indication: If the UE comes from non- 
3GPP access, this flag shall be set in an E-UTRAN 
Initial Attach or in a UE Requested PDN 
Connectivity. 

Operation Indication: This flag shall be set for a 
TAU/RAU procedure with SGW relocation. 
Enhanced SRNS Relocation with SGW relocation 
and X2-based handovers with SGW relocation. 

Direct Tunnel Flag: This flag shall be used on the 
S4 interface and set to 1 if Direct Tunnel is used. 

Piggybacking Supported: This flag shall be set to 1 
only if the MME/ SGW supports the piggybacking 
feature as described in Annex F of 3GPP TS 
23.401 [3]. This flag shall be set to 1 on S5/S8 only 
when both the MME and the SGW support 


Indication 
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piggybacking. 

Change Reporting support Indication: shall be 
used on S4/S1 1 , S5/S8 and set if the SGSN/MME 
supports location Info Change Reporting. 






Sender F-TEID for 
Control Plane 


M 




F-TEID 





PGW S5/S8 Address 
for Control Plane or 
PMIP 


C 


This IE shall be sent on the S11 / S4 interfaces. The TEID 
or GRE Key is set to "0" in the E-UTRAN initial attach, the 
PDP Context Activation and the UE requested PDN 
connectivity procedures. 


F-TEID 


1 


Access Point Name 
(APN) 


M 




APN 





Selection Mode 


C 


This IE shall be included for an E-UTRAN initial attach, a 

PDP Context Activation and a UE requested PDN 

connectivity. 

It shall indicate whether a subscribed APN or a non 

subscribed APN chosen by the MME/SGSN was selected. 


Selection Mode 





CO 


This IE shall be sent by the MME/SGSN on SI 1/S4 
interface during TAU/RAU/HO with SGW relocation. 


PDN Type 


c 


This IE shall be included for an E-UTRAN initial attach, a 
PDP Context Activation and a UE requested PDN 
connectivity. 

This IE shall be set to IPv4, IPv6 or IPv4v6. This is based 
on the UE request and the subscription record retrieved 
from the HSS (for MME see 3GPP TS 23.401 [3], clause 
5.3.1 .1 , and for SGSN see 3GPP TS 23.060 [35], clause 
9.2.1). 


PDN Type 





PDN Address 
Allocation (PAA) 


c 


This IE shall be included for an E-UTRAN initial attach, a 
PDP Context Activation and a UE requested PDN 
connectivity. For PMIP-based S5/S8, this IE shall also be 
included for TAU/RAU/Handover cases involving SGW 
relocation. 

The PDN type field in the PAA shall be set to IPv4, or IPv6 
or IPv4v6 by MME, based on the UE request and the 
subscription record retrieved from the HSS. 
For static IP address assignment (for MME see 3GPP TS 
23.401 [3], clause 5.3.1 .1 , and for SGSN see 3GPP TS 
23.060 [35], clause 9.2.1), the MME/SGSN shall set the 
IPv4 address and/or IPv6 prefix length and IPv6 prefix and 
Interface Identifier based on the subscribed values 
received from HSS, if available. The value of PDN Type 
field shall be consistent with the value of the PDN Type IE, 
if present in this message. 

If static IP address assignment is not used, the IPv4 
address shall be set to 0.0.0.0, and/or the IPv6 Prefix 
Length and IPv6 prefix and Interface Identifier shall all be 
set to zero. 


PAA 





CO 


This IE shall be sent by the MME/SGSN on S1 1/S4 
interface during TAU/RAU/HO with SGW relocation. 


Maximum APN 
Restriction 


c 


This IE shall be included in the E-UTRAN initial attach, 
PDP Context Activation and UE Requested PDN 
connectivity procedures. 

This IE denotes the most stringent restriction as required 
by any already active bearer context. If there are no 
already active bearer contexts, this value is set to the least 
restrictive type. 


APN Restriction 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


c 


This IE represents the APN-AMBR. It shall be included for 
an E-UTRAN initial attach, UE requested PDN 
connectivity, the PDP Context Activation procedure using 
S4 and the PS mobility from the Gn/Gp SGSN to the S4 
SGSN/MME procedures. 


AMBR 





Linked EPS Bearer ID 


c 


This IE shall be included on S4/S11 in RAU/TAU/HO 
except in the Gn/Gp SGSN to MME/S4-SGSN 
RAU/TAU/HO procedures with SGW change to identify the 
default bearer of the PDN Connection 


EBI 





Protocol 


c 


This IE is not applicable to TAU/RAU/Handover. If MME 


PCO 
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Configuration Options 
(PCO) 




receives PCO from UE (during the attach procedures), the 
MME shall forward the PCO IE to SGW. The SOW shall 
also forward it to PGW. 






Bearer Contexts to be 
created 


M 


Several lEs with the same type and instance value shall be 
included as necessary to represent a list of Bearers. 
One bearer shall be included for an "eUTRAN Initial 
Attach", a "PDP Context Activation" or a "UE requested 
PDN Connectivity". 

One or more bearers shall be included for a 
Handover/TAU/RAU with an SGW change. 


Bearer Context 





Bearer Contexts to be 
removed 


C 


This IE shall be included on the S4/S1 1 interfaces for the 

TAU/RAU/Handover cases where any of the bearers 

existing before the TAU/RAU/Handover procedure will be 

deactivated as consequence of the TAU/RAU/Handover 

procedure. 

For each of those bearers, an IE with the same type and 

instance value shall be included. 


Bearer Context 


1 


Trace Information 


C 


This IE shall be included if an SGW and/or a PGW is 
activated. See 3GPP TS 32.422 [18]. 


Trace Information 





Recovery 


C 


This IE shall be included if contacting the peer node for the 
first time. 


Recovery 





MME-FQ-CSID 


C 


This IE shall be included by the MME on the S1 1 interface 
and shall be forwarded by an SGW on the S5/S8 interfaces 
according to the requirements in 3GPP TS 23.007 [17]. 


FO-CSID 





SGW-FQ-CSID 


C 


This IE shall included by the SGW on the S5/S8 interfaces 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


UE Time Zone 





This IE may be included by the MME on the S1 1 interface, 
or by the SGSN on the S4 interface. 


UE Time Zone 





C 


If SGW receives this IE, SGW shall forward it to PGW 
across S5/S8 interface. 


Charging 
Characteristics 


C 


This IE shall be included according to 3GPP TS 32.251 [8] 


Charging 
Characteristics 





Private Extension 







Private Extension 


vs 



Table 7.2.1-2: Bearer Context to be created within Create Session Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 







Bearer TFT 





SI-UeNodeBF-TEID 


C 


This IE shall be included on the S1 1 interface for X2-based 
handover with SGW relocation. 


F-TEID 





S4-U SGSN F-TEID 


C 


This IE shall be included on the S4 interface if the S4-U 
interface is used. 


F-TEID 


1 


S5/S8-U SGW F- 
TEID 


C 


This IE shall be included on the S5/S8 interface for an 
"eUTRAN Initial Attach", a "PDP Context Activation" or a 
"UE Requested PDN Connectivity". 


F-TEID 


2 


S5/S8-U PGW F- 
TEID 


c 


This IE shall be included on the S4 and S1 1 interfaces for 
the TAU/RAU/Handover cases when the GTP-based 
S5/S8 is used. 


F-TEID 


3 


S12RNC F-TEID 


CO 


This IE shall be included on the S4 interface if the SI 2 
interface is used in the Enhanced serving RNS relocation 
with SGW relocation procedure. 


F-TEID 


4 


Bearer Level QoS 


M 




Bearer QoS 
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Table 7.2.1-3: Bearer Context to be removed within Create Session Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





S4-U SGSN F-TEID 


C 


This IE shall be sent on the S4 interface if the S4-U 
interface is used. 


F-TEID 






7.2.2 Create Session Response 

The Create Session Response message shall be sent on the Sll interface by the SGW to the MME, and on the S5/S8 
interface by the PGW to the SGW as part of the procedures: 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 

The message shall also be sent on S4 interface by the SGW to the SGSN, and on the S5/S8 interface by the PGW to the 
SGW as part of the procedures: 

- PDP Context Activation 

The message shall also be sent on the Sll interface by the SGW to the MME as part of the procedures: 
Tracking Area Update procedure with SGW change 
Sl/X2-based handover with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

- 3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure 

- Gn/Gp SGSN to MME Tracking Area Update procedure 

and on the S4 interface by the SGW to the SGSN as part of the procedures: 
Routing Area Update with MME interaction and with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 
Serving RNS relocation 

Combined hard handover and SRNS relocation 

- Combined Cell / URA update and SRNS relocation 
Enhanced serving RNS relocation with SGW relocation 

If handling of default bearer fails, then cause at the message level shall be a failure cause. 
Possible Cause values are: 

"Request accepted". 

"Request accepted partially". 

"New PDN type due to network preference". 
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"New PDN type due to single address bearer only". 

"Request rejected". 

"Missing or unknown APN". 

"GRE key not found". 

"Preferred PDN type not supported". 

"All dynamic addresses are occupied". 

"UE context without TFT already activated". 

"No memory available". 

"PGW not responding". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"System failure". 

"Semantic error in the TFT operation". 

"Syntactic error in the TFT operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filter(s)". 

"Invalid message format". 

"No resources available". 

"User authentication failed". 

"APN access denied - no subscription". 

"APN Restriction type incompatibility with currently active PDN Connection". 

"Version not supported by next peer". 

"Invahd length". 

"Denied in RAT". 

"Protocol type not supported". 
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Table 7.2.2-1 : Information Elements in a Create Session Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Change Reporting 
Action 


C 


This IE shall be included with the appropriate Action field if 
the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





Sender F-TEID for 
Control Plane 


C 


This IE shall be sent on the S1 1/S4 interfaces. For the 
S5/S8 interfaces it is not needed because its content would 
be identical to the IE PGW S5/S8 F-TEID for PMIP based 
interface or for GTP based Control Plane interface. 


F-TEID 





PGW S5/S8 F-TEID 
for PMIP based 
interface or for GTP 
based Control Plane 
interface 


c 


PGW shall include this IE on S5/S8 during the Initial 

Attach, UE requested PDN connectivity and PDP Context 

Activation procedures. 

If SGW receives this IE it shall forward the IE to MME/S4- 

SGSN on S11/S4 interface. 

This IE shall include the TEID in the GTP based S5/S8 

case and the GRE key in the PMIP based S5/S8 case. 

In PMIP based S5/S8 case, same IP address is used for 

both control plane and the user plane communication. 


F-TEID 


1 


PDN Address 
Allocation (PAA) 


c 


This IE shall be included for the E-UTRAN initial attach, the 

PDP Context Activation and the UE requested PDN 

connectivity. 

The PDN type field in the PAA shall be set to IPv4, or IPv6 

or IPv4v6 by the PGW. 

If the DHCPv4 is used for IPv4 address allocation, the IPv4 

address field shall be set to 0.0.0.0. 


PAA 





APN Restriction 


c 


This IE shall be included in the E-UTRAN initial attach, 

PDP Context Activation and UE Requested PDN 

connectivity procedures. 

This IE shall also be included on S4/S1 1 during the Gn/Gp 

SGSN to S4 SGSN/MME RAU/TAU procedures. 

This IE denotes the restriction on the combination of types 

of APN for the APN associated with this EPS bearer 

Context. 


APN Restriction 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


c 


This IE represents the APN-AMBR. It shall be included if 
the received APN-AMBR has been modified by the PCRF. 


AMBR 





Linked EPS Bearer ID 


c 


This IE shall be sent on S4, S1 1 interfaces during Gn/Gp 
SGSN to S4-SGSN/MME RAU/TAU procedure to identify 
the default bearer the PGW selects for the PDN 
Connection. 


EBI 





Protocol 

Configuration Options 
(PCO) 


c 


This IE is not applicable for TAU/RAU/Handover. If PGW 
decides to return PCO to the UE, PGW shall send PCO to 
SGW. If SGW receives the PCO IE, SGW shall forward it 
to MME/SGSN. 


PCO 





Bearer Contexts 
created 


M 


EPS bearers corresponding to Bearer Contexts sent in 

request message. Several lEs with the same type and 

instance value may be included as necessary to represent 

a list of Bearers. 

One bearer shall be included for "eUTRAN Initial Attach", 

"PDP Context Activation" or "UE Requested PDN 

Connectivity ". 

One or more created bearers shall be included for a 

Handover/TAU/RAU with an SGW change. 


Bearer Context 





Bearer Contexts 
marked for removal 


c 


EPS bearers corresponding to Bearer Contexts to be 

removed that were sent in the Create Session Request 

message. 

For each of those bearers an IE with the same type and 

instance value shall be included. 


Bearer Context 


1 


Recovery 


c 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





Charging Gateway 
Name 


c 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface. See NOTE 1 . 


FQDN 





Charging Gateway 
Address 


c 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface. See NOTE 1 . 


IP Address 
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PGW-FQ-CSID 


C 


This IE shall be included by the PGW on the S5/S8 
interfaces and shall be forwarded by the SGW on the S1 1 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by the SGW on the S1 1 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Private Extension 







Private Extension 


VS 


NOTE 1 : Botli Charging Gateway Name and Charging Gateway Address shall not be included at the same 
time. When both are available, the operator configures a preferred value. 



Table 7.2.2-2: Bearer Context Created within Create Session Response 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octets 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, it gives information on the reason. 


Cause 





TFT 







Bearer TFT 





S1-USGWF-TEID 


C 


This IE shall be included on the S1 1 interface if the S1-U 
interface is used. 


F-TEID 





S4-U SGW F-TEID 


C 


This IE shall be included on the S4 interface if the S4-U 
interface is used. 


F-TEID 


1 


S5/S8-U PGW F- 
TEID 


C 


For GTP-based S5/S8, this User Plane IE shall be included 
on S1 1 interface and also on S5/S8 interfaces during the 
"eUTRAN Initial Attach", a "PDP Context Activation" or a 
"UE Requested PDN Connectivity". 


F-TEID 


2 


S12 SGW F-TEID 


C 


This IE shall be included on the S4 interface if the S12 
interface is used. 


F-TEID 


3 


Bearer Level QoS 


C 


This IE shall be included if the received QoS parameters 
have been modified. 


Bearer QoS 





Charging Id 


C 


This IE shall be included on the S5/S8 interface for an E- 
UTRAN initial attach, a PDP Context Activation and a UE 
requested PDN connectivity. 


Charging Id 








If the S5/S8 interface is GTP, this IE may be included on 
the S4 interface, in order to support CAIVIEL charging at 
the SGSN, for a PDP Context Activation, inter S4-SGSN 
RAU with SGW change and Gn/Gp to S4-SGSN RAU. 


Bearer Flags 





Applicable flags are: 

PPC (Prohibit Payload Compression) 


Bearer Flags 






Table 7.2.2-3: Bearer Context marked for removal within a Create Session Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives the information on the reason. 


Cause 






7.2.3 Create Bearer Request 

The direction of this message shall be from PGW to SGW and from SGW to MME/S4-SGSN (see Table 6.1-1). 

The Create Bearer Request message shall be sent on the S5/S8 interface by the PGW to the SGW and on the Sll 
interface by the SGW to the MME as part of the Dedicated Bearer Activation procedure. 

The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
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the SGSN as part of the Secondary PDP Context Activation procedure or the Network Requested Secondary PDP 
Context Activation procedure. 

Table 7.2.3-1 : Information Elements in a Create Bearer Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Procedure 
Transaction Id (PTI) 


C 


This IE shall be sent when the procedure was initiated by a 
UE Requested Bearer Resource Modification Procedure or 
Secondary PDP Context Activation Procedure. 
The PTI shall be the same as the one used in the 
corresponding Bearer Resource Command. 


PTI 





Linked Bearer Identity 
(LBI) 


M 


This IE shall be included to indicate the default bearer 
associated with the PDN connection. 


EBI 





Protocol 

Configuration Options 
(PCO) 







PCO 





Bearer Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 





PGW-FQ-CSID 


C 


This IE shall be included by the PGW on the S5/S8 
interfacesand shall be forwarded by the SOW on the S1 1 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FO-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by the SOW on the S1 1 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FO-CSID 


1 


Change Reporting 
Action 


C 


This IE shall be included with the appropriate Action field If 
the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





Private Extension 







Private Extension 


vs 



NOTE: In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure 
or Secondary PDP Context Activation Procedure, then there will be only one instance of the Bearer 
Contexts IE in the Create Bearer Request. 

Table 7.2.3-2: Bearer Context within Create Bearer Request 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octets 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 


This IE shall be set to 0. 


EBI 





TFT 


M 


This IE can contain both uplink and downlink packet filters 
to be sent to the UE. Downlink packet filters are also used 
by SGW for PIVIIP based S5/8 interfaces. 


Bearer TFT 





S1-USGWF-TEID 


C 


This IE shall be sent on the S1 1 interface if the SI -U 
interface is used. 


F-TEID 





S5/8-U PGW F-TEID 


C 


This IE shall be sent on the S4, S5/S8 and S1 1 interfaces 
for GTP-based S5/S8 interface. The IVIME/SGSN shall 
ignore the IE on S11/S4 for PMIP-based S5/S8 interface. 


F-TEID 


1 


S12SGWF-TEID 


C 


This IE shall be sent on the S4 interface if the S12 
interface is used. 


F-TEID 


2 


S4-U SGW F-TEID 


C 


This IE shall be sent on the S4 interface if the S4-U 
interface is used. 


F-TEID 


3 


Bearer Level QoS 


M 




Bearer QoS 





Charging Id 


C 


This IE shall be sent on the S5/S8 interface. 


Charging Id 








If the S5/S8 interface is GTP, this IE may be sent on the 
S4 interface, in order to support CAMEL charging at the 
SGSN. 


Bearer Flags 





Applicable flags are: 

PPC (Prohibit Payload Compression) 


Bearer Flags 
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7.2.4 Create Bearer Response 



The Create Bearer Response message shall be sent on the S5/S8 interface by the SGW to the PGW, and on the Sll 
interface by the MME to the SGW as part of the Dedicated Bearer Activation procedure. 

The message shall also be sent on the S5/S8 interface by the SGW to the PGW and on the S4 interface by the SGSN to 
the SGW as part of Secondary PDF Context Activation procedure or the Network Requested Secondary PDP Context 
Activation procedure. 

Possible Cause values are: 

"Request accepted". 

"Request accepted partially". 

"Request rejected". 

"Context not found". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"System failure". 

"No memory available". 

"Semantic error in the TFT operation". 

"Syntactic error in the TFT operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filter(s)". 

"Invalid message format". 

"No resources available". 

"Service not supported". 

- "Unable to page UE". 
"UE not responding". 

"Unable to page UE due to Suspension". 

- "UE refuses". 

- "Invahd length". 

- "Denied in RAT". 

"UE context without TFT already activated". 
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Table 7.2.4-1 : Information Elements in a Create Bearer Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Bearer Contexts 


M 


Several lEs with this type and instance value shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





MME-FQ-CSID 


C 


This IE shall be included by the MME on the S1 1 
interfaceand shall be forwarded by the SGW on the S5/S8 
interfaces according to the requirements in 3GPP TS 
23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by the MME on the S1 1 interface 
and shall be forwarded by the SGW on the S5/S8 
interfaces according to the requirements in 3GPP TS 
23.007 [171. 


FQ-CSID 


1 


Protocol 

Configuration Options 
(PCO) 


C 


If the UE includes the PCO IE, then the MME/SGSN shall 
copy the content of this IE transparently from the PCO IE 
included by the UE. If the SGW receives PCO from 
MME/SGSN, SGW shall forward it to the PGW. 


PCO 





UE Time Zone 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


UE Time Zone 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


User Location 
Information (ULI) 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


ULI 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


Private Extension 







Private Extension 


vs 



Table 7.2.4-2: Bearer Context within Create Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, it gives information on the reason. 


Cause 





SI-UeNodeBF-TEID 


C 


This IE shall be sent on the S1 1 interface if the SI -U 
interface is used. 


F-TEID 





S1-USGWF-TEID 


C 


This IE shall be sent on the S1 1 interface. It shall be used 
to correlate the bearers with those in the Create Bearer 
Request. 


F-TEID 


1 


S5/8-U SGW F-TEID 


C 


This IE shall be sent on the S5/S8 interfaces. 


F-TEID 


2 


S5/8-U PGW F-TEID 


C 


This IE shall be sent on the S5/S8 interfaces. It shall be 
used to correlate the bearers with those in the Create 
Bearer Request. 


F-TEID 


3 


S12RNC F-TEID 


C 


This IE shall be sent on the S4 interface if the SI 2 
interface is used. 


F-TEID 


4 


S12 SGW F-TEID 


c 


This IE shall be sent on the S4 interface. It shall be used to 
correlate the bearers with those in the Create Bearer 
Request. 


F-TEID 


5 


S4-U SGSN F-TEID 


c 


This IE shall be sent on the S4 interface if the S4-U 
interface is used. 


F-TEID 


6 


S4-U SGW F-TEID 


c 


This IE shall be sent on the S4 interface. It shall be used to 
correlate the bearers with those in the Create Bearer 
Request. 


F-TEID 


7 
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7.2.5 Bearer Resource Command 

A Bearer Resource Command message shall be sent from a MME to a SGW and forwarded to PGW as a part of the UE 
requested bearer resource allocation procedure or UE requested bearer resource modification procedure. 

The message shall also be sent on the S4 interface by a SGSN to a SGW and on the S5/S8 interface by a SGW to a 
PGW as part of the MS initiated PDF Context modification procedure, or secondary PDF context activation procedure. 

Table 7.2.5-1 specifies the presence of the lEs in the message. 

Table 7.2.5-1 : Information Elements in a Bearer Resource Command 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Linked EPS Bearer ID 
(LBI) 


M 




EBI 





Procedure 
Transaction Id (PTI) 


M 




PTI 





Flow Quality of 
Service (Flow QoS) 


C 


This IE shall be included, except for a Bearer resource 
release. 


Flow QoS 





Traffic Aggregate 
Description (TAD) 


M 


The TAD consists of the description of the packet filter(s) 
for a traffic flow aggregate. 


TAD 





RAT Type 


C 


This IE shall be included for MS initiated PDP Context 
modification procedure and Secondary PDP context 
activation procedure. 


RAT Type 





Serving Network 





This IE may be included in the IVIS initiated PDP Context 
modification procedure. 


Serving Network 





User Location 
Information (ULI) 





This IE may be included in the IVIS initiated PDP Context 
modification procedure. 


ULI 





EPS Bearer ID 


c 


This IE indicates the EPS Bearer that needs to be 
modified. It shall be included for MS initiated PDP Context 
modification procedure. For EUTRAN this IE shall be 
present if it is triggered by the NAS Bearer Resource 
Modification Request message and its value shall be set to 
the value of the "EPS bearer identity for packet filter" IE 
received in that NAS message. 


EBI 


1 


Indication Flags 





This IE may be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Change Reporting Support Indication: this flag may 
be included in the MS initiated PDP Context 
modification procedure. 

Direct Tunnel Flag: this flag may be included in the 
MS initiated PDP Context Modification procedure. 


Indication 





S4-U SGSN F-TEID 





This IE shall be included on the S4 interface when direct 
tunnel is not established in the MS initiated PDP Context 
modification procedure 


F-TEID 





S12RNCF-TEID 





This IE shall be included on the S4 interface when direct 
tunnel flag is set to 1 in the MS initiated PDP Context 
modification procedure. 


F-TEID 


1 


Protocol 

Configuration Options 
(POO) 







PCO 





Private Extension 







Private Extension 


vs 



NOTE: Depending on the protocol type on the S5/S8 interface, the SGW or the FGW will determine if the UE is 
requesting an Allocation/Modification operation of bearer resources for a traffic flow aggregate based on 
the TFT operation code and the packet filter ID value in the Traffic Aggregate (TAD) IE and/or the 
presence of the EFS Bearer ID IE. 
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7.2.6 Bearer Resource Failure Indication 

A Bearer Resource Failure Indication shall be sent by the PGW to an SGW and forwarded to the MME to indicate 
failure of the UE requested bearer resource allocation procedure or UE requested bearer resource modification 
procedure. 

The message shall also be sent by a PGW to an SGW and forwarded to an SGSN as part of the failure of an MS 
initiated PDF Context modification procedure or secondary PDF context activation procedure. 

Table 7.2.6-1 specifies the presence of the lEs in the message. 

Possible Cause values are: 

"No resources available". 

"No memory available". 

"User authentication failed". 

"System failure". 

"Semantic error in the TAD operation". 

"Syntactic error in the TAD operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filter(s)". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"Invalid message format". 

"Collision with network initiated request". 

"Invalid length". 

"Service denied". 

Table 7.2.6-1 : Information Elements in a Bearer Resource Failure Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Linked EPS Bearer ID 


M 




EBI 





Procedure 
Transaction ID (PTI) 


M 




PTI 





Recovery 







Recovery 





Private Extension 







Private Extension 


vs 



7.2.7 Modify Bearer Request 

The direction of this message shall be from MME/S4-SGSN to SGW and/or from SGW to PGW (see Table 6.1-1). 

The Modify Bearer Request message shall only be sent on the Sll interface by the MME to the SGW and on the S5/S8 
interfaces by the SGW to the PGW as part of the procedures: 

- E-UTRAN Tracking Area Update without SGW Change 

UE triggered Service Request 
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SI -based Handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 

3G SGSN to MME combined hard handover and SRNS relocation procedure 

X2-based handover without SGW relocation 

It shall also only be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interfaces by the SGW to the 
PGW as part of the procedures: 

Routeing Area Update with MME interaction and without SGW change 

Routeing Area Update with MME interaction and with SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs 

- Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure 
lu mode RA Update Procedure 

Serving RNS Relocation Procedure 

Combined Hard Handover and SRNS Relocation Procedure 

- Combined Cell / URA Update and SRNS Relocation Procedure 
Enhanced Serving RNS Relocation without SGW relocation 
UE Initiated Service Request Procedure 

- lu mode to A/Gb mode Intra SGSN Change 

- A/Gb mode to lu mode Intra SGSN Change 

- lu mode to A/Gb mode Inter-SGSN Change 

- A/Gb mode to lu mode Inter-SGSN Change 

Paging Response with no established user plane on S4 
PDP Context Activation Procedure 
only on the S4 interface by the SGSN to the SGW as part of the procedures: 
RAB Assignment Procedure 

- SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support procedures and SRVCC from UTRAN 
(HSPA) to UTRAN or GERAN with DTM HO support. 

and only on the S5/S8 interfaces by the SGW to the PGW as part of the procedures: 

Tracking Area Update procedure with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 
X2 based handover with SGW relocation 

- Gn/Gp SGSN to MME Tracking Area Update 
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Enhanced Serving RNS Relocation with SGW relocation 
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Table 7.2.7-1 : Information Elements in a Modify Bearer Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


ME Identity (MEI) 


C 


This IE shall be sent on the S5/S8 interfaces for the Gn/Gp 
SGSN to MME TAU. 


MEI 





User Location 
Information (ULI) 


C 


The MME/SGSN shall include this IE for 
TAU/RAU/Handover procedures if the PGW has requested 
location information change reporting and MME/SGSN 
support location information change reporting. An 
MME/SGSN which supports location information change 
shall include this IE for UE-initiated Service Request 
procedure if the PGW has requested location information 
change reporting and the UE"s location info has changed. 
The SGW shall include this IE on S5/S8 if it receives the 
ULI from MME/SGSN. 


ULI 





CO 


This IE shall also be included on the S4/S1 1 interface for a 
TAU/RAU/Handover with MME/SGSN change without 
SGW change procedure, if the level of support changes. 
The MME shall include the ECGI/TAI in the ULI, the SGSN 
shall include the CGI/SAI in the ULI. 
The SGW shall include this IE on S5/S8 if it receives the 
ULI from MME/SGSN. 


Serving Networl< 


c 


This IE shall be sent on S5/S8 for a TAU with an 
associated MME change and the SGW change. 


Serving Network 





CO 


This IE shall be included on S5/S8 for a RAU/Handover 
with an associated SGSN/MME change and SGW change. 


RAT Type 


c 


This IE shall be sent on the S1 1 interface for a TAU with 

anSGSN interaction, UE triggered Service Request or an 1- 

RAT Handover. 

This IE shall be sent on the S5/S8 interface for achange of 

RAT type. 

This IE shall be sent on the S4 interface for aRAU with 

MME interaction, a RAU with an SGSN change, a UE 

Initiated Service Request or an l-RAT Handover. 


RAT Type 





Indication Flags 


c 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags are: 

ISRAI: This flag shall be used on S4/S1 1 interface 
and set to 1 if the ISR is established between the 
MME and the S4 SGSN. 

Handover Indication: This flag shall be set for an 
E-UTRAN Initial Attach or for a UE Requested 
PDN Connectivity, if the UE comes from a non- 
3GPP access. 

Direct Tunnel Flag: This flag shall be used on the 
S4 interface and set to 1 if Direct Tunnel is used. 

Change Reporting support Indication: shall be 
used on S4/S1 1 , S5/S8 and set if the SGSN/MME 
supports location Info Change Reporting. This flag 
should be ignored by SGW if no message is sent 
on S5/S8. 

Change F-TEID support Indication: This flag shall 
be used on S4/S1 1 for an IDLE state UE initiated 
TAU/RAU procedure and set to 1 to allow the 
SGW changing the GTP-U F-TEID. 


Indication 





Sender F-TEID for 
Control Plane 


c 


This IE shall be sent on the S1 1 and S4 interfaces for a 
TAU/RAU/ Handover with MME/SGSN change and without 
any SGW change. 

This IE shall be sent on the S5 and S8 interfaces for a 
TAU/RAU/Handover with a SGW change. 


F-TEID 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


c 


The APN-AMBR shall be sent for the PS mobility from the 
Gn/Gp SGSN to the S4 SGSN/MME procedures.. 


AMBR 
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Delay Downlink 
Packet Notification 
Request 


C 


This IE shall be sent on the S1 1 interface for a UE 
triggered Service Request. 


Delay Value 





Bearer Contexts to be 
modified 


C 


This IE shall not be sent on the S5/S8 interface for a UE 

triggered Service Request. 

When Handover Indication flag is set to 1 (i.e., for 

EUTRAN Initial Attach or UE Requested PDN Connectivity 

when the UE comes from non-3GPP access), the PGW 

shall ignore this IE. See NOTE 1 

Several lEs with the same type and instance value may be 

included as necessary to represent a list of Bearers to be 

modified. 


Bearer Context 





Bearer Contexts to be 
removed 


C 


This IE shall be included on the S4 and S1 1 interfaces for 
the TAU/RAU/Handover and Service Request procedures 
where any of the bearers existing before the 
TAU/RAU/Handover procedure and Service Request 
procedures will be deactivated as consequence of the 
TAU/RAU/Handover procedure and Service Request 
procedures. 

For each of those bearers, an IE with the same type and 
instance value, shall be included. 


Bearer Context 


1 


Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





UE Time Zone 





This IE may be included by the MME on the S1 1 interface 
or by the SGSN on the S4 interface. 


UE Time Zone 





C 


If SGW receives this IE, SGW shall forward it to PGW 
across S5/S8 interface. 


MME-FQ-CSID 


C 


This IE shall be included by MME on S1 1 and shall be 
forwarded by SGW on S5/S8 according to the 
requirements in 3GPP TS 23.007 [17]. 


FO-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by SGW on S5/S8 according to 
the requirements in 3GPP TS 23.007 [17]. 


FO-CSID 


1 


Private Extension 







Private Extension 


vs 


NOTE 1 : This requirement is introduced for backwards compatibility reasons. If Bearer Contexts to be modified 
IE{s) is received in the Modify Bearer Request message, the PGW shall include corresponding 
Bearer Contexts modified IE(s) in the Modify Bearer Response message. 
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Table 7.2.7-2: Bearer Context to be modified within IVIodify Bearer Request 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octets 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





S1 eNodeB F-TEID 


C 


This IE shall be sent on the S1 1 interface if the S1 -U is 
being used: 

for an eUTRAN initial attach 

a UE triggered Service Request 

in all TAU/handover cases, except during TAU 
without the active flag (see 3GPP TS 24.301 [23]) 
being set. 

If an IVIME is aware that the eNodeB supports both IP 
address types, the MME shall send both IP addresses 
within an F-TEID IE. If only one IP address is included, 
then the SGW shall assume that the eNodeB does not 
support the other IP address type. 


F-TEID 





S5/8-U SGW F-TEID 


C 


This IE shall be sent on the S5/S8 interfaces for a 
Handover or a TAU/RAU with a SGW change. 


F-TEID 


1 


S12RNC F-TEID 


C 


If available, this IE shall be included if the message is sent 
on the S4 interface if SI 2 interface is being used (this IE 
will be not available in a SRVCG handover, which is 
indicated by the VB flag being set in the Bearer Flags IE). 
If an S4-SGSN is aware that the RNC supports both IP 
address types, the S4-SGSN shall send both IP addresses 
within an F-TEID IE. If only one IP address is included, 
then the SGW shall assume that the RNC does not support 
the other IP address type. 


F-TEID 


2 


S4-U SGSN F-TEID 


C 


If available, this IE shall be included if the message is sent 
on the S4 interface, if S4-U is being used (this IE will be 
not available in a SRVCG handover, which is indicated by 
the VB flag being set in the Bearer Flags IE). If an S4- 
SGSN supports both IP address types, the S4-SGSN shall 
send both IP addresses within an F-TEID IE. If only one IP 
address is included, then the SGW shall assume that the 
S4-SGSN does not support the other IP address type. 


F-TEID 


3 


Bearer Flags 





Applicable flags are: 

VB (Voice Bearer) indicator is set to indicate a 
voice bearer for PS-to-CS SRVCC handover over 
the S4 interface. 


Bearer Flags 






Table 7.2.7-3: Bearer Context to be removed withiin IVIodify Bearer Request 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octets 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 






7.2.8 Modify Bearer Response 

The Modify Bearer Response message shall be sent on the SI 1 interface by the SGW to the MME and on the S5/S8 
interfaces by the PGW to the SGW as part of the procedures: 

- E-UTRAN Tracking Area Update without SGW Change 

UE triggered Service Request 
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SI -based Handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 

3G SGSN to MME combined hard handover and SRNS relocation procedure 

X2-based handover without SGW relocation 

It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interfaces by the PGW to the SGW 
as part of the procedures: 

Routeing Area Update with MME interaction and without SGW change 

Routeing Area Update with MME interaction and with SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs 

- Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure 
lu mode RA Update Procedure 

Serving RNS Relocation Procedure 

Combined Hard Handover and SRNS Relocation Procedure 

- Combined Cell / URA Update and SRNS Relocation Procedure 
Enhanced Serving RNS Relocation without SGW relocation 
UE Initiated Service Request Procedure 

- lu mode to A/Gb mode Intra SGSN Change 

- A/Gb mode to lu mode Intra SGSN Change 

- lu mode to A/Gb mode Inter-SGSN Change 

- A/Gb mode to lu mode Inter-SGSN Change 

Paging Response with no established user plane on S4 

PDP Context Activation Procedure 
on the S4 interface by the SGSN to the SGW as part of: 

RAB Assignment Procedure 
and on the S5/S8 interfaces by the PGW to the SGW as part of: 

Tracking Area Update procedure with SGW change 

- Gn/Gp SGSN to S4 SGSN Routing Area Update 
X2 based handover with SGW relocation 

- Gn/Gp SGSN to MME Tracking Area Update 
Enhanced Serving RNS Relocation with SGW relocation 
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If handling of default bearer fails, then Cause at the message level shall be a failure cause. 
Possible Cause values are: 

"Request accepted". 

"Request accepted partially". 

"Request rejected". 

- "Context not found". 
"Mandatory IE incorrect". 
"Mandatory IE missing". 
"Conditional IE missing". 

- "System failure". 

"No memory available" 
"Invalid message format". 
"Service not supported". 
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Table 7.2.8-1 : Information Elements in a Modify Bearer Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





MSISDN 


C 


This IE shall be included on S5/S8 interfaces by the PGW 
if it is stored in its UE context and if this message is 
triggered due to TAU/RAU/HO with SGW relocation. 


MSISDN 





Linked EPS Bearer ID 


C 


This IE shall be sent on S5/S8 when the UE moves from a 
Gn/Gp SGSN to the S4 SGSN or MME to identify the 
default bearer the PGW selects for the PDN Connection. 
This IE shall also be sent by SGW on S1 1 , S4 during 
Gn/Gp SGSN to S4-SGSN/MME HO procedures to identify 
the default bearer the PGW selects for the PDN 
Connection. 


EBI 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


C 


This IE shall be included in the PS mobility from Gn/Gp 
SGSN to the S4 SGSN/MME procedures if the received 
APN-AMBR has been modified by the PCRF. 


AMBR 





APN Restriction 


C 


This IE denotes the restriction on the combination of types 
of APN for the APN associated with this EPS bearer 
Context. This IE shall be included over S5/S8 interfaces, 
and shall be forwarded over SI 1/S4 interfaces during 
Gn/Gp SGSN to MME/S4-SGSN handover procedures. 
This IE shall also be included on S5/S8 interfaces during 
the Gn/Gp SGSN to S4 SGSN/MME RAU/TAU 
procedures. 

The target MME or SGSN determines the Maximum APN 
Restriction using the APN Restriction. 


APN Restriction 





Protocol 

Configuration Options 
(PCO) 


C 


If SGW receives this IE from PGW on GTP or PMIP based 
S5/S8, the SGW shall forward PCO to MME/S4-SGSN 
during Inter RAT handover from the UTRAN or from the 
GERAN to the E-UTRAN. See NOTE 2. 


PCO 





Bearer Contexts 
modified 


c 


EPS bearers corresponding to Bearer Contexts to be 
modified that were sent in Modify Bearer Request 
message. Several lEs with the same type and instance 
value may be included as necessary to represent a list of 
the Bearers which are modified. 


Bearer Context 





Bearer Contexts 
marked for removal 


c 


EPS bearers corresponding to Bearer Contexts to be 
removed sent in the Modify Bearer Request message. 
Shall be included if request message contained Bearer 
Contexts to be removed. 

For each of those bearers an IE with the same type and 
instance value shall be included. 


Bearer Context 


1 


Change Reporting 
Action 


c 


This IE shall be included with the appropriate Action field If 
the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





Charging Gateway 
Name 


c 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
interface during SGW relocation and when the UE moves 
from Gn/Gp SGSN to S4-SGSN/MME. See NOTE 1 . 


FQDN 





Charging Gateway 
Address 


c 


When Charging Gateway Function (CGF) Address is 
configured, the PGW shall include this IE on the S5 
Interface during SGW relocation and when the UE moves 
from Gn/Gp SGSN to S4-SGSN/MME. See NOTE 1 . 


IP Address 





PGW-FQ-CSID 


c 


This IE shall be included by PGW on S5/S8and shall be 
forwarded by SGW on S1 1 according to the requirements 
in 3GPPTS 23.007 [17]. 


FO-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by SGW on S1 1 according to the 
requirements in 3GPP TS 23.007 [17]. 


FO-CSID 


1 


Recovery 


c 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 


NOTE 1 : Both Charging Gateway Name and Charging Gateway Address shall not be included at the same 

time. When both are available, the operator configures a preferred value. 
NOTE 2: If MME receives the IE, but no NAS message is sent, MME discards the IE. 
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Table 7.2.8-2: Bearer Context modified within lUlodify Bearer Response 



Octets 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octets 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 





S1 SGW F-TEID 


C 


This IE shall be used on the S1 1 interface, if the SI 
interface is used. See NOTE 1 


F-TEID 





S12SGWF-TEID 


C 


This IE shall be included on the S4 interface if the S12 
interface is being used. See NOTE 1 


F-TEID 


1 


S4-U SGW F-TEID 


C 


This IE shall be present if used on the S4 interface if the 
S4-U interface is being used. See NOTE 1 


F-TEID 


2 


Charging ID 


C 


This IE shall be present on the S5/S8 interface if this 
message is triggered due to one of the following 
procedures: 

- TAU/RAU/HO with SGW relocation 

- TAU/RAU/HO from Gn/Gp SGSN to MME/S4- 
SGSN 


Charging ID 








If S5/S8 interface is GTP, this IE may be sent on the S4 
interface, in order to support CAIVIEL charging at the 
SGSN, for the following procedures: 

inter-SGSN RAU/Handover/SRNS Relocation 

without SGW change. 

inter-SGSN Handover/SRNS Relocation with SGW 
change. 


Bearer Flags 


CO 


Applicable flags are: 

PPC (Prohibit Payload Compression): This flag 
shall be sent on the S5/S8 and the S4 interfaces 
at S4-SGSN relocation. 


Bearer Flags 





NOTE 1 : The SGW shall not change its F-TEID for a given interface during the Handover, Service Request, E- 
UTRAN Initial Attach, UE Requested PDN connectivity and PDF Context Activation procedures. The 
SGW F-TEID shall be same for S1-U, S4-U and S12. 

During Handover and Service Request the target eNodeB/RNC/SGSN may use a different IP type 
than the one used by the source eNodeB/RNC/SGSN. In order to support such a scenario, the SGW 
F-TEID should contain both an IPv4 address and an IPv6 address (see also subclause 8.22 "F- 
TEID"). 



Table 7.2.8-3: Bearer Context marlted for removal within IVIodify Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 






7.2.9 Delete Session Request and Delete Bearer Request 
7.2.9.1 Delete Session Request 

The direction of this message shall be from MME/S4-SGSN to SGW and from SGW to PGW (see Table 6.1-1). 

A Delete Session Request message shall be sent on the Sll interface by the MME to the SGW and on the S5/S8 
interface by the SGW to the PGW as part of the procedures: 

- EUTRAN Initial Attach 
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- UE, HSS or MME Initiated Detach 

UE or MME Requested PDN Disconnection 

It shall also be sent on the S4 interface by the SGSN to the SGW, and on the S5/S8 interface by the SGW to the PGW 
as part of 

- MS, HLR or SGSN initiated detach procedure 

- Combined GPRS/IMSI Attach 

MS and SGSN Initiated PDN connection Deactivation Procedure using S4 
On the S 11 interface by the MME to the SGW as part of the procedures: 
Tracking Area Update with SGW Change 

- S 1 Based Handover with SGW Change 
X2 Based Handover with SGW Relocation 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 
Inter RAT handover cancel with SGW change 

- MME to 3G Gn/Gp SGSN combined hard handover and SRNS relocation procedure 

- MME to SGSN Routing Area Update 

- E-UTRAN to Gn/Gp SGSN Inter RAT handover 
SI Based handover cancel with SGW change 

- Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access 
And on the S4 interface by the SGSN to the SGW as part of 

Enhanced Serving RNS Relocation with SGW relocation using S4 
Routing Area Update with SGW change 

- SGSN to MME Tracking Area Update 
SRNS Relocation Cancel Procedure Using S4 
Inter RAT with SGW change handover cancel 
Serving RNS relocation with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

If there are any procedure collisions, the Delete Session Request shall have precedence over any other Tunnel 
Management message. 

During the handover procedure the Delete Session Request message shall not release the indirect data forwarding 
tunnels. 

Possible Cause values are: 

- "ISR deactivation ". 

Table 7.2.9.1-1 specifies the presence of the lEs in the message. 
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Table 7.2.9.1-1 : Information Elements in a Delete Session Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


C 


If ISR is being de-activated, the Cause IE shall be included 
and its value shall indicate that the SOW shall delete the 
bearer resources by sending Delete Bearer Request to the 
MME/SGSN on which ISR was activated with Cause value 
"ISR deactivation". 


Cause 





Linked EPS Bearer ID 
(LBI) 


C 


This IE shall be included to indicate the default bearer 
associated with the PDN being disconnected unless in the 
handover/TAU/RAU with SOW relocation procedures. 


EBI 





User Location 
Information (ULI) 


c 


The IVIME/SGSN shall include this IE for the Detach 
procedure if the PGW has requested location information 
change reporting and MME/SGSN support location 
information change reporting. The SGW shall include this 
IE on S5/S8 if it receives the ULI from MME/SGSN. 


ULI 





CO 


The MME shall include this IE for the UE or MME 
Requested PDN Disconnection procedure if the PGW has 
requested location information change reporting and the 
MME support location information change reporting. 
The SGW shall include this IE on S5/S8 if it receives the 
ULI from the MME. 


Indication Flags 


c 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Operation Indication: This flag shall be set over 
S4/S1 1 interface if the SGW needs to forward the 
Delete Session Request message to the PGW. 
This flag shall not be set if the ISR associated GTP 
entity sends this message to the SGW in the 
Detach procedure. This flag shall also not be set to 
1 in the SRNS Relocation Cancel Using S4/lnter 
RAT handover Cancel procedure with SGW 
change/S1 Based handover Cancel procedure with 
SGW change. 

Scope Indication: if request corresponds to 
TAU/RAU/Handover/SRNS Relocation Cancel 
Using S4/lnter RAT handover Cancel procedure 
with SGW change/Si Based handover Cancel 
procedure with SGW change, then this bit is set. 

See NOTE 1 . 


Indication 





Protocol 

Configuration Options 
(PCO) 


c 


If the UE includes the PCO IE, then the MME/SGSN shall 

copy the content of this IE transparently from the PCO IE 

included by the UE. 

If SGW receives the PCO IE, SGW shall forward it to 

PGW. 


PCO 





Originating Node 


c 


This IE shall be included if the ISR associated GTP entity 
sends this message to SGW in Detach procedure to 
denote the type of the node originating the message. If this 
IE is included in the Delete Session Request message, the 
SGW in ISR activated state deactivates ISR, releases the 
Originating Node related EPS Bearer contexts information 
and shall not forward this message to the PGW. 


Node Type 





CO 


This IE shall be included if the ISR associated GTP entity 
sends this message to SGW in TAU/RAU/HO with SGW 
change procedure to denote the type of the node 
originating the message. 


Private Extension 





None 


Private Extension 


vs 


NOTE 1 : For the Indication Flags, the combination (Operation Indication, Scope Indication) = 1 ,1 shall be 
considered an error if received. 
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7.2.9.2 Delete Bearer Request 

The direction of this message shall be from PGW to SGW and from SGW to MME/S4-SGSN (see Table 6.1-1). 
A Delete Bearer Request message shall be sent as part of the following procedures: 

PGW or MME initiated bearer deactivation procedures, 

UE requested Bearer Resource Modification, 

MS and SGSN Initiated Bearer Deactivation procedure using S4 or 

PGW initiated bearer deactivation procedure using S4. 

In the above cases, this Request is sent by the PGW to the SGW and shall be forwarded to the MME or S4-SGSN. 

The message shall also be sent on the S4/S 1 1 interface by the SGW to the SGSN/MME to delete the bearer resources on 
the other ISR associated CN node if the ISRAI flag is not set in the Modify Bearer Request message 

The message shall also be sent on the S4/S 1 1 interface by the SGW to the SGSN/MME to delete the bearer resources on 
the other ISR associated CN node in the TAU/RAU/Handover procedures if the ISR related Cause IE is included in the 
Delete Session Request message. 

Possible Cause values are: 

- "RAT changed from 3GPP to Non-3GPP", 

- "ISR deactivation". 

Table 7.2.9.2-1 specifies the presence of lEs in this message. 
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Table 7.2.9.2-1 : Information Elements in a Delete Bearer Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Linked EPS Bearer ID 
(LBI) 


C 


If the request corresponds to the bearer deactivation 
procedure in case all bearers belonging to a PDN 
connection shall be released, then this IE shall be included 
to indicate the default bearer associated with the PDN 
being disconnected. 

This IE shall be included only when the EPS Bearer ID is 
not present in the message. 


EBI 





EPS Bearer IDs 


C 


This IE shall be used for bearers different from the default 
one, i.e., for dedicated bearers. In this case at least one 
dedicated bearer shall be included. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


EBI 


1 


Failed Bearer 
Contexts 





This IE may be included if the request corresponds to 
IVIME initiated bearer deactivation procedure. This IE shall 
contain the list of failed bearers if partial Bearer Contexts 
included in the Delete Bearer Command message could 
not be deleted. 


Bearer Context 





Procedure 
Transaction Id (PTI) 


c 


If the request corresponds to UE requested bearer 
resource modification procedure for an E-UTRAN, this IE 
shall be included. 


PTI 





Protocol 

Configuration Options 
(PCO) 


c 


PGW shall include Protocol Configuration Options (PCO) 
IE, if available. 

If SGW receives this IE, SGW shall forward it to 
SGSN/MME on the S4/S1 1 interface. 


PCO 





PGW-FQ-CSID 


c 


This IE shall be included by the PGW on the S5/S8 
interface and shall be forwarded by the SGW on the S1 1 
interface according to the requirements in 3GPP TS 
23.007 [17]. 


FO-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by the SGW on the S1 1 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FO-CSID 


1 


Cause 


c 


This IE shall be sent on SI 1/S4 and S5/S8 interfaces if the 
message is caused by handover without optimization 
occurs from 3GPP to non-3GPP. In this case the Cause 
value shall be set to "RAT changed from 3GPP to Non- 
3GPP". 

This IE shall also be sent on S11/S4 interfaces when the 
SGW requests to delete all bearer contexts in an IVIME or 
S4-SGSN due to ISR deactivation, and its Cause value 
shall then be set to "ISR deactivation". 


Cause 





Private Extension 







Private Extension 


vs 



NOTE: In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure 
for an E-UTRAN, then there will be only one instance of the EPS Bearer IDs IE in the Delete Bearer 
Request. 

Table 7.2.9.2-2: Bearer Context within Delete Bearer Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate the reason of the unsuccessful 
handling of the bearer. 


Cause 
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7.2.10 Delete Session Response and Delete Bearer Response 
7.2.10.1 Delete Session Response 

A Delete Session Response message shall be sent on the SI 1 interface by the SGW to the MME and on the S5/S8 
interface by the PGW to the SGW as part of the following procedures: 

- EUTRAN Initial Attach 

- UE, HSS or MME Initiated Detach 

UE or MME Requested PDN Disconnection 

It shall also be sent on the S4 interface by the SGW to the SGSN and on the S5/S8 interface by the PGW to the SGW as 
part of the procedures: 

- MS, HLR or SGSN initiated detach procedure 

- Combined GPRS/IMSI Attach 

MS and SGSN Initiated Default Bearer Deactivation Procedure using S4 
On the S 11 interface by the SGW to the MME as part of the procedures: 
Tracking Area Update with SGW Change 

- S 1 Based Handover with SGW Change 
X2 Based Handover with SGW Relocation 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 
Inter RAT handover cancel with SGW change 

- MME to 3G Gn/Gp SGSN combined hard handover and SRNS relocation procedure 

- MME to SGSN Routing Area Update 

- E-UTRAN to Gn/Gp SGSN Inter RAT handover 
SI Based handover cancel with SGW change 

- Optimised Active Handover: E-UTRAN Access to CDMA2000 HRPD Access 
And on the S4 interface by the SGW to the SGSN as part of the procedures: 

Enhanced Serving RNS Relocation with SGW relocation using S4 
Routing Area Update with SGW change 

- SGSN to MME Tracking Area Update 
Serving RNS relocation with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 

The sending entity shall include Cause IE in the Delete Session Response message. The IE indicates if the peer has 
deleted the bearer, or not. 

Possible Cause values are: 

"Request accepted". 
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"Context not found". 
"Mandatory IE incorrect". 
"Conditional IE missing". 
"Invalid message format". 
Table 7.2.10.1-1 specifies the presence of the lEs in the message. 

Table 7.2.10.1-1 : Information Elements in a Delete Session Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 


C 


This IE shall be included If contacting the peer for the first 
time 


Recovery 





Protocol 

Configuration Options 
(PCO) 


C 


PGW shall include Protocol Configuration Options (PCO) 
IE, if available. 

If SGW receives this IE, SOW shall forward it to 
SGSN/MME on the S4/S1 1 interface. 


PCO 





Private Extension 







Private Extension 


vs 



7.2.10.2 Delete Bearer Response 

The Delete Bearer Response shall be sent as a response of Delete Bearer Request. 
Possible Cause values are: 

"Request accepted". 

"Request accepted partially". 

"Request rejected". 

"Context not found". 

"Mandatory IE incorrect". 

"Conditional IE missing". 

"System failure". 

"Invalid message format". 
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Table 7.2.10.2-1 : Information Elements in Delete Bearer Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Linked EPS Bearer ID 
(LBI) 


C 


If the response corresponds to the bearer deactivation 
procedure in case all the bearers associated with the 
default bearer of a PDN connection shall be released, this 
IE shall be included to indicate the default bearer 
associated with the PDN being disconnected. 


EBI 





Bearer Contexts 


C 


It shall be used for bearers different from default one. In 
this case at least one bearer shall be included. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 
Used for dedicated bearers. When used, at least one 
dedicated bearer shall be present. 


Bearer Context 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





MME-FQ-CSID 


C 


This IE shall be included by MIVIE the on S1 1 interface and 
shall be forwarded by the SGW on S5/S8 interface 
according to the requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


c 


This IE shall be included by the SGW on the S5/S8 
interface according to the requirements in 3GPP TS 
23.007 [171. 


FQ-CSID 


1 


Protocol 

Configuration Options 
(PCO) 


c 


If the UE includes the PCO IE, then the MME/SGSN shall 
copy the content of this IE transparently from the PCO IE 
included by the UE. If the SGW receives PCO from the 
MME/SGSN, SGW shall forward it to the PGW. 


PCO 





UE Time Zone 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


UE Time Zone 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


User Location 
Information (ULI) 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


ULI 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


Private Extension 







Private Extension 


vs 



Table 7.2.10.2-2: Bearer Context within Delete Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 






7.2.1 1 Downlink Data Notification messages 
7.2.1 1 .1 Downlink Data Notification 

A Downlink Data Notification message shall be sent: 

on the S 1 1 interface by the SGW to the MME as a part of the network triggered service request procedure; 

on the S4 interface by the SGW to the SGSN as part of Paging with no established user plane on S4, SGW 
triggered paging with S4; 
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on the S4 interface by the SGW to the S4-SGSN to re-establish all previous released bearer(s) for a UE, upon 
receipt of downlink data for a UE in connected mode but without corresponding downlink bearer available; 

NOTE: This may occur e.g. if the S4-SGSN releases some but not all the bearers of the UE as specified in 
subclause 12.7.2.2 of 3GPP TS 23.060 [35]. 

- on S 1 1/S4 interface by SGW to MME/S4-SGSN if the SGW has received an Error Indication (see 3GPP TS 
29.281 [13]) from eNodeB/RNC across S1-U/S12 interface. Respective SGW and MME/S4-SGSN functionahty 
is specified in 3GPP TS 23.007 [17]. 

Table 7.2.11.1-1 specifies the presence of the lEs in the message. 

Table 7.2.11 .1-1: Information Elements in a Downlink Data Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 





If SGW receives an Error Indication from eNodeB/RNC, 
the SGW may send tlie Cause IE with value "Error 
Indication received from RNC/eNodeB" to MME/S4-SGSN 
as specified in 3GPP TS 23.007 [17]. 


Cause 





Private Extension 







Private Extension 


vs 



7.2.11.2 



Downlink Data Notification Acknowledge 



A Downlink Data Notification Acknowledge shall be sent from a MME/SGSN to a SGW in response to Downlink Data 
Notification with an indication of success, or failure when MME/SGSN has reachability or abnormal conditions. 

Possible Cause values are: 

"Request accepted". 
- "Unable to page UE". 

"Invalid message format". 

"Context not found". 

"Unable to page UE due to Suspension". 
Table 7.2.11.2-1 specifies the presence of the lEs in the message. 

Table 7.2.11.2-1: Information Elements in a Downlink Data Notification Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Data Notification 
Delay 


C 


The MME/SGSN shall include an adaptive delay indication 
to the SGW to delay the number of Data Notification 
indications, if the rate of Downlink Data Notification event 
occurrence in the MME/SGSN becomes significant (as 
configured by the operator) and the MME/SGSN's load 
exceeds an operator configured value. 


Delay Value 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





Private Extension 







Private Extension 


vs 



7.2.11.3 



Downlink Data Notification Failure Indication 



A Downlink Data Notification Failure indication shall be sent from an MME/SGSN to a SGW indicating that the UE 
did not respond to paging. It shall also be sent in the case that the UE responded to the page with a Service Request but 
that the MME has rejected the request by sending a Service Reject to the UE. It may happen, for example, because the 
requested service is not supported or there is a bearer context mismatch. 
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This message should not be used after an MME/SGSN successfully receives the Service Request message from the UE 
in the Network Triggered Service Request procedure as defined in the 3GPP TS 23.401 [3]. 

NOTE: Either the Modify Bearer Request message or the Delete Bearer Command message is used by the 

MME/SGSN to indicate a possible failure case after an MME/SGSN successfully receives the Service 
Request message from the UE. 

Possible Cause values are: 

"UE not responding". 

"Service denied". 
Table 7.2.11.3-1 specifies the presence of the lEs in the message. 

Table 7.2.11.3-1 : Information Elements in a Downlink Data Notification Failure Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


vs 



7.2.12 Delete Indirect Data Forwarding Tunnel Request 

The Delete Indirect Data Forwarding Tunnel Request message is sent on the S4/S1 1 interface by the SGSN/MME to the 
SGW to delete the Indirect Forwarding Tunnels in the Source SGW/Target SGW as part of the following procedures: 

SI -based handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

MME to 3G SGSN combined hard handover and SRNS relocation procedure 
3G SGSN to MME combined hard handover and SRNS relocation procedure 
Inter RAT handover Cancel 
S 1 -based handover Cancel 

Table 7.2.12-1: Information Element in Delete Indirect Data Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 





Vendor or operator specific information 


Private Extension 


VS 



7.2.13 Delete Indirect Data Forwarding Tunnel Response 

The Delete Indirect Data Forwarding Tunnel Response message is sent on the S4/S 1 1 interface by the SGW to the 
SGSN/MME as part of the following procedures: 

SI -based handover 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 

- E-UTRAN to UTRAN lu mode Inter RAT handover 
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- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

MME to 3G SGSN combined hard handover and SRNS relocation procedure 
3G SGSN to MME combined hard handover and SRNS relocation procedure 
Inter RAT handover Cancel 
S 1 -based handover Cancel 
Possible Cause values are: 
"Request accepted". 
"Request accepted partially" 
"Request rejected" 
"No memory available" 

- "System failure". 
"Invalid message format". 

- "Context not found". 

Table 7.2.13-1 : Information Element in Delete Indirect Data Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 


This IE shall indicate if the deletion of indirect tunnel is 
successful, and if not, gives information on the reason. 


Cause 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 



7.2.14 Modify Bearer Command and Failure Indication 
7.2.14.1 Modify Bearer Command 

The Modify Bearer Command shall be sent on the Sll interface by the MME to the SGW and on the S5/S8 interface by 
the SGW to the PGW as part of the HSS Initiated Subscribed QoS Modification procedure or SQCI flag is set to 1 in the 
Context Response message. 

It shall also be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interface by the SGW to the PGW as 
part of the HSS Initiated subscribed QoS modification procedure or SQCI flag is set to 1 in the Context Response 

message. 

Table 7.2.14.1-1 : Information Elements in a IVIodify Bearer Command 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


APN-Aggregate 
IVIaximum Bit Rate 
(APN-AMBR) 


M 


This IE shall contain the APN-AIVIBR value received by the 
MME/SGSN from the HSS. 


AMBR 





Bearer Context 


M 


Only one IE with this type and instance value shall be 
included and this shall represent the Default Bearer. 


Bearer Context 





Private Extension 







Private Extension 


VS 
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Table 7.2.14.1-2: Bearer Context within lUlodify Bearer Command 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 


This IE shall contain the default bearer ID. 


EBI 





Bearer Level QoS 


C 


IVIandatory if other parameters than the APN-AIVIBR have 
been changed 


Bearer QoS 





CO 


This IE shall also be included when QCI and ARP have not 
been changed and if the SQCI flag is set to 1 in the 
Context Response message. 



7.2.14.2 Modify Bearer Failure Indication 

The Modify Bearer Failure Indication shall be sent on the S5/S8 interface by the PGW to the SGW and on the S 1 1 
interface by the SGW to the MME as part of failure of HSS Initiated Subscribed QoS Modification procedure. 

It shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to the SGSN as 
part of failure of HSS Initiated subscribed QoS modification. 

Cause IE indicates that an EPS bearer has not been updated in the PGW. 

Possible Cause values are: 

"Context not found" 

"No resources available". 

"No memory available". 

"System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"Invalid message format". 
- "Invalid length". 

"Service denied". 

Table 7.2.14.2-1: Information Elements in a IVIodify Bearer Failure Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





Private Extension 







Private Extension 


VS 



7.2.15 Update Bearer Request 

The direction of this message shall be from PGW to SGW and/or from SGW to MME/S4-SGSN (see Table 6.1-1). 

For GTP based S5/S8, the Update Bearer Request shall be sent by the PGW to the SGW and forwarded to the MME as 
part of the following procedures: 

- PGW Initiated Bearer Modification with Bearer QoS Update 
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- HSS Initiated Subscribed QoS Modification 

- PGW Initiated Bearer Modification without Bearer QoS Update 

UE Request Bearer Resource Modification procedure 

The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
the SGSN as part of the following procedures: 

- PGW Initiated EPS Bearer Modification 

Execution part of MS-Initiated EPS Bearer Modification 

SGSN-Initiated EPS Bearer Modification Procedure using S4 

For PMIP based S5/S8, the Update Bearer Request shall be sent on the S 1 1 interface by the SGW to the MME and on 
the S4 interface by the SGW to the SGSN. 

Table 7.2.15-1 specifies the presence requirements and the conditions of the lEs in the message. 

Table 7.2.15-1 : Information Elements in an Update Bearer Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Bearer Contexts 


M 


This IE shall contain contexts related to bearers that need 
QoS/TFT modification. Several lEs with this type and 
instance values shall be included as necessary to 
represent a list of Bearers. 

If there is no QoS/TFT modification, only one IE with this 
type and instance value shall be included. 


Bearer Context 





Procedure 
Transaction Id (PTI) 


C 


If the request corresponds to UE requested bearer 
resource modification procedure for an E-UTRAN or MS 
initiated EPS bearer modification procedure, this IE shall 
be included. 

PTI shall be the same as the one used in the 
corresponding Bearer Resource Command 


PTI 





Protocol 

Configuration Options 
(PCO) 


C 


PGW shall include Protocol Configuration Options (PCO) 
IE, if available. 

If SGW receives this IE, SGW shall forward it to 
SGSN/MME on the S4/S1 1 interface. 


PCO 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 


APN-AMBR 


AMBR 





Change Reporting 
Action 


C 


This IE shall be included with the appropriate Action field If 
the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





PGW-FQ-CSID 


C 


This IE shall be by PGW on S5/S8 and shall be forwarded 
by SGW on S1 1 according to the requirements in 3GPP 
TS 23.007 [17]. 


FO-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by SGW on S1 1 according to the 
requirements in 3GPP TS 23.007 [17]. 


FO-CSID 


1 


Private Extension 







Private Extension 


vs 



NOTE: In the case that the procedure was initiated by a UE Requested Bearer Resource Modification Procedure 
for an E-UTRAN or MS initiated EPS bearer modification procedure, then there will be only one instance 
of the Bearer Contexts IE in the Update Bearer Request. 
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Table 7.2.15-2: Bearer Context within Update Bearer Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 


C 


This IE shall be included if message relates to Bearer 
IVIodification and TFT change. 


Bearer TFT 





Bearer Level QoS 


C 


This IE shall be included if QoS modification is requested 


Bearer QoS 





Bearer Flags 





Applicable flags: 

PPC (Prohibit Payload Compression) 


Bearer Flags 






7.2.16 Update Bearer Response 

An Update Bearer Response shall be sent from a MME/SGSN to a SGW and forwarded to the PGW as a response to an 
Update Bearer Request message. 

Table 7.2.16-1 specifies the presence requirements and the conditions of the lEs in the message. 

Cause IE indicates if an EPS bearer has been modified in the MME/SGSN or not. The EPS Bearer has not been 
modified in the MME if the Cause IE value differs from "Request accepted" or "Request accepted partially". Possible 
Cause values are: 

"Request accepted". 

"Request accepted partially" 

"Request rejected" 

"Context not found" 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"System failure". 

"Semantic error in the TFT operation". 

"Syntactic error in the TFT operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filter(s)". 

"Invalid message format". 

- "InvaUd length". 

- "Denied in RAT". 

- "UE refuses". 

"UE context without TFT already activated". 
"No resources available". 

- "Unable to page UE". 
"UE not responding". 

"Unable to page UE due to Suspension". 
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Table 7.2.16-1 : Information Elements in an Update Bearer Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Bearer Contexts 


M 


This IE shall contain contexts related to bearers for which 
QoS/TFT modification was requested. Several lEs with this 
type and instance values shall be included as necessary to 
represent a list of Bearers 


Bearer Context 





Protocol 

Configuration Options 
(PCO) 


C 


IVIME/SGSN shall include PCO IE if such information was 

received from the UE. 

If SGW receives this IE, SGW shall forward It to PGW on 

the S5/S8 interface. 

This IE shall be included if the Cause IE contains the value 

"Request accepted". 


PCO 





Recovery 


C 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





MME-FQ-CSID 


C 


This IE shall be included by MIVIE on S1 1 and shall be 
forwarded by SGW on S5/S8 according to the 
requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included by SGW on S1 1 according to the 
requirements in 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Indication Flags 





This IE may be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Direct Tunnel Flag: this flag may be included if the Direct 

Tunnel is used. 


Indication 





UE Time Zone 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


UE Time Zone 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


User Location 
Information (ULI) 





This IE is optionally included by the MME on the S1 1 
interface or by the SGSN on the S4 interface. 


ULI 





CO 


The SGW shall forward this IE on the S5/S8 interface if the 
SGW supports this IE and it receives it from the 
MME/SGSN. 


Private Extension 







Private Extension 


vs 



Table 7.2.16-2: Bearer Context within Update Bearer Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE Indicates if the bearer handling was successful, 
and if not, gives information on the reason. 


Cause 





S4-U SGSN F-TEID 


C 


This IE shall be included on the S4 interface when direct 
tunnel is not established. 


F-TEID 





S12RNCF-TEID 


C 


This IE shall be included on the S4 Interface when direct 
tunnel flag is set to 1 . 


F-TEID 


1 



7.2.17 Delete Bearer Command and Failure Indication 



7.2.17.1 



Delete Bearer Command 



A Delete Bearer Command message shall be sent on the S 11 interface by the MME to the SGW and on the S5/S8 
interface by the SGW to the PGW as a part of the eNodeB requested bearer release or MME-Initiated Dedicated Bearer 
Deactivation procedure. 
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The message shall also be sent on the S4 interface by the SGSN to the SGW and on the S5/S8 interface by the SGW to 
the PGW as part of the MS and SGSN Initiated Bearer Deactivation procedure using S4. 

Table 7.2.17.1-1: Information Elements in Delete Bearer Command 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Bearer Contexts 


M 


This IE sliall be used to indicate dedicated bearers. When 
used, at least one dedicated bearer shall be present. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


Bearer Context 





Private Extension 







Private Extension 


vs 



Table 7.2.17.1-2: Bearer Context within Delete Bearer Command 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 






7.2.17.2 



Delete Bearer Failure Indication 



A Delete Bearer Failure Indication shall be sent on the S5/S8 interface by the PGW to the SGW and on the SI 1 
interface by the SGW to the MME as part of failure of eNodeB requested bearer release or MME Initiated Dedicated 
Bearer Deactivation procedure. 

The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
the SGSN as part of failure of MS and SGSN Initiated Bearer Deactivation procedure using S4. 

This message shall be sent back if all the bearers included in the Delete Bearer Command message could not be deleted. 

Cause IE indicates that an EPS bearer has not been deleted in the PGW. 

Possible Cause values are: 

"Context not found" 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"System failure". 

"Invalid message format". 

Table 7.2.17.2-1: Information Elements in a Delete Bearer Failure Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Bearer Context 


M 


This IE shall contain the list of failed bearers. 


Bearer Context 





Recovery 


C 


This IE shall be included If contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 
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Table 7.2.17.2-2: Bearer Context within Delete Bearer Failure Indication 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall Indicate the reason of the unsuccessful 
handling of the bearer. 


Cause 






7.2.18 Create Indirect Data Forwarding Tunnel Request 

The Create Indirect Data Forwarding Tunnel Request message shall be sent on the S11/S4 interface by the MME/SGSN 
to the SGW as part of the Handover procedures. 

Table 7.2.18-1 specifies the presence requirements and the conditions of the IBs in the message. 

Table 7.2.18-1: Information Elements in a Create Indirect Data Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


C 


This IE shall be included by the MME/SGSN if the SGW 
that the MME/SGSN selects for indirect data forwarding is 
different from the SGW already in use for the UE as the 
anchor point. 
SeeNOTEL 


IMSI 





Sender F-TEID for 
Control Plane 


C 


This IE shall be included by the MME/SGSN if the SGW 
that the MME/SGSN selects for indirect data forwarding is 
different from the SGW already in use for the UE as the 
anchor point. 
SeeNOTEL 


F-TEID 





Bearer Contexts 


M 


Several lEs with this type and instance value may be 
included as necessary to represent a list of Bearers 


Bearer Context 





Recovery 


CO 


This IE shall be included if contacting the peer for the first 
time. 


Recovery 





Private Extension 







Private Extension 


vs 


NOTE 1 : The SGW which is hosting the UE's bearer{s) is considered as the (local) anchor point. Unlike the 
PGW, the SGW may change due to mobility between eNodeBs, or E-UTRAN and GERAN/UTRAN 
supported with S4 based architecture. In these cases the new SGW where the UE's bearer(s) are 
moved, becomes the new local anchor point. A source IVIME/SGSN may select an SGW for indirect 
data forwarding which is different than the source (anchor) SGW. Similarly, a target MME/SGSN may 
select an SGW for indirect data forwarding which is different than the target (anchor) SGW. 
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Table 7.2.18-2: Bearer Context within Create Indirect Data Forwarding Tunnel Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





eNodeBF-TEIDfor 
DL data forwarding 


C 


Target eNodeB F-TEID. 

This IE shall be present in the message sent from the 
target IVIME to the target SGW, or shall be included in the 
message sent from the source SGSN/IVIME to the source 
SGW if the eNodeB F-TEID for DL data forwarding is 
included in the Forward Relocation Response message. 


F-TEID 





SGWF-TEIDforDL 
data forwarding 


C 


Target SGW F-TEID 

This IE shall be present in the message sent from the 

source MME/SGSN to the source SGW if SGW F-TEID for 

DL data forwarding is included in the Forward Relocation 

Response message. This F-TEID is assigned by the SGW 

that the target IVIME/SGSN selects for indirect data 

forwarding. 


F-TEID 


1 


SGSN F-TEID for DL 
data forwarding 


C 


Target SGSN F-TEID 

This IE shall be present in the message sent from the 
target SGSN to the target SGW in E-UTRAN to 
GERAN/UTRAN inter RAT handover with SGW relocation 
procedure, or shall be included in the message sent from 
the source IVIME to the source SGW if the SGSN F-TEID 
for DL data forwarding is included in the Forwarding 
Relocation Response message. 


F-TEID 


2 


CO 


This IE shall also be present in the message sent from the 
source IVIME to the source SGW if the SGSN Address for 
User Traffic and the Tunnel Endpoint Identifier Data II are 
included in the GTPv1 Forward Relocation Response 
message as specified in D.3.3 of 3GPP TS 23.401 [3]. 


RNC F-TEID for DL 
data forwarding 


c 


Target RNC F-TEID 

This IE shall be present in the message sent from the 
target SGSN to the target SGW in E-UTRAN to UTRAN 
inter RAT handover with SGW relocation procedure, or 
shall be included in the message sent from the source 
MME to the source SGW if the RNC F-TEID for DL data 
forwarding is included in the Forwarding Relocation 
Response message. 


F-TEID 


3 


CO 


This IE shall also be present in the message sent from the 
source MME to the source SGW if the RNC IP address 
and TEID are included in the RAB Setup Information 
and/or the Additional RAB Setup Information in the GTPv1 
Forward Relocation Response message as specified in 
D.3.3 of 3GPPTS 23.401 [3]. 


eNodeBF-TEIDfor 
UL data forwarding 





Target eNodeB F-TEID. 

If available this IE may be present in the message, which is 
sent during the intra-EUTRAN HO from the target MME to 
the target SGW, or may be included in the message sent 
from the source MME to the source SGW if the eNodeB F- 
TEID for data UL forwarding is included in the Forward 
Relocation Response message. 


F-TEID 


4 


SGW F-TEID for UL 
data forwarding 





Target SGW F-TEID 

If available this IE may be present in the message, which is 
sent during the intra-EUTRAN HO from the source MME to 
the source SGW if SGW F-TEID for UL data forwarding is 
included in the Forward Relocation Response message. 
This F-TEID is assigned by the SGW that the target MME 
selects for indirect data forwarding. 


F-TEID 


5 
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7.2.19 Create Indirect Data Forwarding Tunnel Response 

A Create Indirect Data Forwarding Tunnel Response message shall be sent by the SGW to the MME/SGSN as a 
response to a Create Indirect Data Forwarding Tunnel Request message. 

Table 7.2.19-1 specifies the presence requirements and the conditions of the lEs in the message. 

The Cause value indicates if the Indirect Data Forwarding Tunnels has been created in the SGW or not. No Indirect 
Data Forwarding Tunnels have been created in the SGW if the Cause differs from "Request accepted" or "Request 
accepted partially". Possible Cause values are: 

"Request accepted". 

"Request accepted partially". 

"Data forwarding not supported". 

"No resources available". 

"System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"Invalid message format". 

"Context not found". 

Table 7.2.19-1 : Information Elements in a Create Indirect Data Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Sender F-TEID for 
Control Plane 


C 


This IE shall be included by an SGW if the SGW receives a 

Sender F-TEID for Control Plane IE from an IVIME/SGSN in 

a Create Indirect Data Forwarding Tunnel Request 

message. 

See also NOTE 1 in Table 7.2.1 8-1 . 


F-TEID 





Bearer Contexts 


M 


Several lEs with this type and instance value may be 
included as necessary to represent a list of Bearers 


Bearer Context 





Recovery 


CO 


This IE shall be included if contacting the peer for the first 
time 


Recovery 





Private Extension 







Private Extension 


vs 
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Table 7.2.19-2: Bearer Context within Create Indirect Data Forwarding Tunnel Response 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





Cause 


M 


This IE shall indicate if the tunnel setup was successful, 
and if not, gives information on the reason. 


Cause 





S1-USGWF-TEID 
for DL data 
forwarding 


C 


This IE shall be included in the response sent from the 
source SGW to the source MME. 


F-TEID 





S12SGWF-TEIDfor 
DL data forwarding 


C 


S12 usage only. 

This IE shall be included in the response sent from the 

source SGW to the source SGSN. 


F-TEID 


1 


S4-U SGW F-TEID 
for DL data 
forwarding 


C 


S4-U usage only. 

This IE shall be included in the response sent from the 

source SGW to the source SGSN. 


F-TEID 


2 


SGW F-TEID for DL 
data forwarding 


c 


This IE shall be included in the response message sent 
from the target SGW to the target MME/SGSN. 


F-TEID 


3 


S1-U SGW F-TEID 
for UL data 
forwarding 





If available this IE may be included in the response sent 
during the intra-EUTRAN HO from the source SGW to the 
source MME. 


F-TEID 


4 


SGW F-TEID for UL 
data forwarding 





If available this IE may be included in the response 
message sent during the intra-EUTRAN HO from the target 
SGW to the target MME. 


F-TEID 


5 


NOTE 1 : For DL data forwarding if the SGW does not liave enough information to decide which of the F-TEID 
instance from S1-U, S12, S4-U and SGW to include in the message, it may include all of them. 

NOTE 2: For UL data forwarding if the SGW does not have enough information to decide which of the F-TEID 
instance from S1-U and SGW to include in the message, it may include both of them. 



7.2.20 Void 

7.2.21 Release Access Bearers Request 

The Release Access Bearers Request message shall sent on the S 11 interface by the MME to the SGW as part of the S 1 
release procedure. 

The message shall also be sent on the S4 interface by the SGSN to the SGW as part of the procedures: 

RAB release using S4 

lu Release using S4 

- READY to STANDBY transition within the network 

Table 7.2.21-1 : Information Element in Release Access Bearers Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


List of RABs 


C 


Shall be present on S4 interface when this message is 

used to release a subset of all active RABs according to 

the RAB release procedure. 

Several lEs with this type and instance values shall be 

included as necessary to represent a list of RABs to be 

released. 


EBI 





Private Extension 





Vendor or operator specific information 


Private Extension 


vs 



£75/ 



3GPP TS 29.274 version 8.10.0 Release 8 



66 



ETSI TS 129 274 V8.10.0 (2011-06) 



7.2.22 Release Access Bearers Response 



The Release Access Bearers Response message is sent on the S 1 1 interface by the SGW to the MME as part of the S 1 
release procedure. 

The message shall also be sent on the S4 interface by the SGW to the SGSN as part of the procedures: 

- RAB release using S4 
lu Release using S4 

- READY to STANDBY transition within the network 
Possible Cause values are: 

"Request accepted". 
"Request accepted partially". 
"Request rejected". 

- "Context not found". 

- "System failure". 
"Invalid message format". 
"Mandatory IE incorrect". 
"Conditional IE missing". 

Table 7.2.22-1 : Information Element in Release Access Bearers Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 


None 


Cause 





Recovery 





This IE shall be included if contacting the peer for the first 
time 


Recovery 





Private Extension 





Vendor or operator specific information 


Private Extension 


vs 



7.2.23 Stop Paging Indication 



A Stop Paging Indication message shall be sent on the S 1 1/S4 interface by the SGW to the MME/SGSN as a part of the 
network triggered service request procedure. 

Table 7.2.23-1 specifies the presence of the lEs in the message. 

Table 7.2.23-1 : Information Elements in a Stop Paging Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 







Private Extension 


VS 



7.3 Mobility Management Messages 
7.3.1 Forward Relocation Request 

A Forward Relocation Request message shall be sent from the source MME to the target MME over SIO interface as 
part of SI -based handover relocation procedure from the source MME to the target SGSN, or from the source SGSN to 
the target MME over S3 interface as part of Inter RAT handover and combined hard handover and SRNS relocation 
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procedures, or from source SGSN to the target SGSN over S 16 interface as part of SRNS Relocation and PS handover 
procedures. 

A Forward Relocation Request message shall also be sent from the source MME to the target SGSN over S3 interface 
as part of SRVCC from E-UTRAN to UTRAN or GERAN with DTM HO support procedures and from source SGSN 
to the target SGSN over S 16 interface as part of SRVCC from UTRAN (HSPA) to UTRAN or GERAN with DTM HO 
support. 

Forward Relocation procedure across SIO interface (when Kasme is taken into use) shall be performed according to the 
Rules on Concurrent Running of Security Procedures, which are specified in 3GPP TS 33.401 [12]. 

Table 7.3.1-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.1-1: Information Elements in a Forward Relocation Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





Sender's F-TEIDfor 
Control Plane 


M 


This IE specifies the address and the TEID for control 
plane message which is chosen by the source 
MME/SGSN. 

This information shall be used by the target MME/SGSN to 
the source MME/SGSN when sending Forward Relocation 
Response message, Forward Access Context 
Acknowledge message and Forward Relocation Complete 
Notification message. 


F-TEID 





MME/SGSN UE EPS 
PDN Connections 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of PDN 
Connections 


PDN Connection 





SGWS11/S4IP 
Address andTEIDfor 
Control Plane 


M 




F-TEID 


1 


SGW node name 


C 


This IE shall be included if the source MME or SGSN has 
the source SGW FQDN. 


FQDN 





MME/SGSN UE MM 
Context 


M 




MM Context 





Indication Flags 


C 


This IE shall be included if any of the flags are set to 1 . 

Direct Forwarding Indication: This flag shall be set 
to 1 if direct forwarding is supported in the S1 
based handover procedure. This flag shall not be 
set to 1 if the message is used for other handover 
procedures. 

Idle mode Signalling Reduction Supported Indication flag: 
This flag shall be set to 1 if the source 
MME/SGSN is capable to establish ISR for the 
UE. 

Change Reporting support indication flag: 

This flag shall be set to 1 if the Source S4- 
SGSN/MME supports Location Change Reporting 
mechanism. 


Indication 





E-UTRAN 

Transparent 

Container 


C 


This IE shall be included if the message is used for 
UTRAN/GERAN to E-UTRAN inter RAT handover 
procedure, intra RAT handover procedure and 3G SGSN 
to MME combined hard handover and SRNS relocation 
procedure. 


F-Container 





UTRAN Transparent 
Container 


c 


This IE shall be included if the message is used for PS 
handover to UTRAN lu mode procedures, SRNS relocation 
procedure and E-TURAN to UTRAN inter RAT handover 
procedure. 


F-Container 


1 


Target Identification 


c 


This IE shall be included if the message is used for SRNS 
relocation procedure and handover to UTRAN/E-UTRAN 
procedures. 


Target 
Identification 





HRPD access node 
S101 IP address 


c 


This IE shall be included only if the HRPD pre registration 
was performed at the source MME 


IP-Address 





1XIWSS102IP 
address 


c 


This IE shall be included only if the 1xRTT CS fallback pre 
registration was performed at the source MME 


IP-Address 


1 


RAN Cause 


c 


This IE is the information from the source eNodeB, the 
source MME shall include this IE in the message. 


F-Cause 





RANAP Cause 


c 


This IE is the information from the source RNC, the source 
SGSN shall include this IE in the message. 


F-Cause 


1 


BSS Container 


c 


This IE shall be included if the message is used for PS 
handover to GERAN A/Gb mode and E-UTRAN to GERAN 
A/Gb mode inter RAT handover procedure. 


F-Container 


2 


Source Identification 


c 


This IE shall be included on the S1 6 interface if the 
message is used for PS handover from GERAN/UTRAN to 
GERAN A/Gb mode. 


Source 
Identification 





BSSGP Cause 


c 


This IE is the information from source BSS, the source 
SGSN shall include this IE in the message. 


F-Cause 


2 
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Selected PLMN ID 


C 


The old MME/SGSN shall include this IE if the selected 
PLMN identity is available. The Selected PLMN ID IE 
indicates the core network operator selected for the UE in 
a shared network. 


Selected PLMN 
ID 





Recovery 


C 


If contacting the peer for the first time 


Recovery 





Trace Information 


C 


This IE shall be included when session trace is active for 
this IMSI/IMEI. 


Trace Information 





Subscribed RFSP 
Index 


CO 


This IE shall be included during inter-MME/SGSN mobility 
procedures, if the source MME/SGSN receives it from an 
HSS. 


RFSP Index 





RFSP Index in Use 


CO 


This IE shall be included only during inter-MME/SGSN 
mobility procedures, if the source MME/SGSN supports the 
feature. 


RFSP Index 


1 


Private Extension 







Private Extension 


vs 



The PDN Connection grouped IE shall be coded as depicted in Table 7.3.1-2. 

Table 7.3.1-2: MME/SGSN UE EPS PDN Connections within Forward Relocation Request 



Octet 1 


PDN Connection IE Type = 109 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


APN 


M 




APN 





APN Restriction 


C 


This IE denotes the restriction on the combination of types 
of APN for the APN associated with this EPS bearer 
Context. The target MME or SGSN determines the 
Maximum APN Restriction using the APN Restriction. 
If available, the source MME/S4SGSN shall include this IE. 


APN Restriction 





Selection Mode 


CO 


When available, this IE shall be included by the source 
MME/S4-SGSN. 


Selection Mode 





IPv4 Address 


C 


This IE shall not be included if no IPv4 Address is 
assigned. See NOTE 1. 


IP Address 





IPv6 Address 


c 


This IE shall not be included if no IPv6 Address is 
assigned. 


IP Address 


1 


Linked EPS Bearer ID 


M 


This IE identifies the default bearer of the PDN 
Connection. 


EBI 





PGW S5/S8 IP 
Address for Control 
Plane or PMIP 


M 


This IE shall include the TEID in the GTP based S5/S8 
case and the GRE key in the PMIP based S5/S8 case. 


F-TEID 





PGW node name 


C 


This IE shall be included if the source MME or SGSN has 
the PGW FODN. 


FQDN 





Bearer Contexts 


C 


Several lEs with this type and instance values may be 
included as necessary to represent a list of Bearers. 


Bearer Context 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 




AMBR 





Charging 
characteristics 


C 


This IE shall be present if charging characteristics was 
supplied by the HSS to the MME/SGSN as a part of 
subscription information. 


Charging 
characteristics 





Change Reporting 
Action 


C 


This IE shall be included whenever available at the source 
MME/SGSN. 


Change Reporting 
Action 





NOTE 1 : For deferred IPv4 address allocation, if the MME/S4-SGSN receives the PDN address "0.0.0.0" from 
PGW during "eUTRAN Initial Attach", "PDP Context Activation", "UE requested PDN Connectivity", 
then the MME/S4-SGSN shall include this IPv4 address "0.0.0.0". 



The Bearer Context grouped IE shall be coded as depicted in Table 7.3. 1-3. 
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Table 7.3.1-3: Bearer Context within IVIME/SGSN UE EPS PDN Connections within Forward Relocation 

Request 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 


C 


This IE shall be present if a TFT is defined for this bearer. 


Bearer TFT 





SGWS1/S4/S12IP 
Address andTEIDfor 
user plane 


M 




F-TEID 





PGW S5/S8 IP 
Address andTEIDfor 
user plane 


C 


This IE shall be present for GTP based S5/S8. 


F-TEID 


1 


Bearer Level QoS 


M 




Bearer Level QoS 





BSS Container 





The MME/S4 SGSN shall include the Packet Flow ID, 
Radio Priority, SAPI, PS Handover XID parameters in the 
TAU/RAU/Handover procedure, if available. 


F-Container 





Transaction Identifier 


C 


This IE shall be sent over S3/S10/S16 if the UE supports 
A/Gb and/or lu mode. 


Ti 





Bearer Flags 





Applicable flags are: 

VB (Voice Bearer) indicator is set to indicate a voice 
bearer for PS-to-CS SRVCC handover 


Bearer Flags 






7.3.2 Forward Relocation Response 

A Forward Relocation Response message shall be sent as a response to Forward Relocation Request during SI -based 
handover procedure, Inter RAT handover procedures, SRNS Relocation procedure and PS handover procedures. 

Table 7.3.2-1 specifies the presence requirements and conditions of the lEs in the message. 

Cause IE indicates if the relocation has been accepted, or not. The relocation has not been accepted by the target 
MME/SGSN if the Cause IE value differs from "Request accepted". Possible Cause values are: 

"Request accepted". 

"System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"No resources available". 

"Invalid message format". 

"Relocation failure". 
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Table 7.3.2-1 : Information Elements in a Forward Relocation Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Sender's F-TEIDfor 
Control Plane 


C 


if the Cause iE contains the value "Request accepted", the 
target IViME/SGSN shall include this IE in Forward 
Relocation Response message. 

This information shall be used by the source MME/SGSN 
to the target IVIME/SGSN when sending Forward 
Relocation Complete Acknowledge message and Forward 
Access Context Notification message. 


F-TEID 





indication Flags 


C 


This iE shall be included if any of the flags are set to 1 . 
SGW Change indication: 

This flag shall be set to 1 if the target IViME/SGSN 

has selected a new SGW. 


indication 





List of Set-up Bearers 


C 


The list of set-up Bearers IE contains the EPS bearer 
identifiers of the Bearers that were successfully allocated 
in the target system during a handover procedure. This iE 
shall be included if the Cause IE contains the value 
"Request accepted". 

Several iEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 





List of Set-up RABs 


c 


The list of set-up RABs iE contains the RAB identifiers of 
the RABs that were successfully allocated in the target 
system. This iE shall be included if the Cause iE contains 
the value "Request accepted". 
Several iEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


Bearer Context 


1 


List of Set-up PFCs 





The list of set-up PFCs iE contains the Paci<et Flow 
identifies of the PFCs that were successfully allocated in 
the target system during a PS handover to/from GERAN or 
inter RAT handover to/from GERAN. if the Cause IE 
contains the value "Request accepted", this iE may be 
included. 


Bearer Context 


2 


eNodeB Cause 


c 


if the Cause iE contains the value "Request accepted", this 
iE is mandatory if cause value is contained in S1-AP 
message. 


F-Cause 





RANAP Cause 


c 


if the Cause iE contains the value "Request accepted", this 
iE is mandatory if cause value is contained in RANAP 
message. 


F-Cause 


1 


E-UTRAN 

Transparent 

Container 


c 


This iE is conditionally included only during a handover to 
E-UTRAN and contains the radio-related and core network 
information, if the Cause iE contains the value "Request 
accepted", this iE shall be included. 


F-Container 





UTRAN Transparent 
Container 


c 


This iE is conditionally included only during a handover to 
UTRAN and contains the radio-related and core network 
information, if the Cause iE contains the value "Request 
accepted", this iE shall be included. 


F-Container 


1 


BSS Container 


c 


This IE is conditionally included only during a handover to 
GERAN and contains the radio-related and core network 
information, if the Cause iE contains the vaiue "Request 
accepted", this iE shall be included. 


F-Container 


2 


BSSGP Cause 


c 


For handover to GERAN, if a cause value is received from 
the Target BSC, the BSSGP Cause iE shall be included 
and shall be sent to the cause value received from the 
target BSC. 


F-Cause 


2 


Private Extension 







Private Extension 


VS 



Bearer Context IE in this message is specified in Table 7.3.2-2, the source system shall use this IE for data forwarding 
in handover. 
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Table 7.3.2-2: Bearer Context 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


C 


This IE shall be included if the message is used for S1 - 
Based handover procedure. 

This IE shall be included if the message is used for SRNS 
relocation procedure and Inter RAT handover to/from lu 
mode procedures. 


EBI 





Packet Flow ID 


C 


This IE shall be included if the message is used for PS 
handover and Inter RAT handover to/from A/Gb mode 
procedures. 


Packet Flow ID 





eNodeBF-TEIDfor 
DL data forwarding 


c 


This IE shall be included for the message sent from the 
target MME, if the DL Transport Layer Address and DL 
GTP TEID are included in the "SAE Bearers Admitted List" 
oftheSlAP: HANDOVER REQUEST ACKNOWLEDGE 
and direct forwarding or indirect forwarding without SGW 
change is applied. 


F-TEID 





eNodeBF-TEIDfor 
UL data forwarding 





This IE may be included for the message sent from the 
target MME during the intra-EUTRAN HO, if the UL 
Transport Layer Address and UL GTP TEID are included in 
the "SAE Bearers Admitted List" of the S1 AP: HANDOVER 
REOUEST ACKNOWLEDGE and direct forwarding or 
indirect forwarding without SGW change is applied. 


F-TEID 


1 


SGWF-TEIDforDL 
data forwarding 


c 


This SGW F-TEID shall be included for indirect data 
forwarding. 


F-TEID 


2 


RNCF-TEIDforDL 
data forwarding 


c 


This RNC F-TEID shall be included in the message sent 
from SGSN, if the target system decides using RNC F- 
TEID for data forwarding. 


F-TEID 


3 


SGSN F-TEID for DL 
data forwarding 


c 


This SGSN F-TEID shall be included in the message sent 
from SGSN, if the target system decides using SGSN F- 
TEID for data forwarding. 


F-TEID 


4 


SGW F-TEID for UL 
data forwarding 





If available this SGW F-TEID may be included for indirect 
data forwarding during the intra-EUTRAN HO. 


F-TEID 


5 



7.3.3 Forward Relocation Complete Notification 

A Forward Relocation Complete Notification message shall be sent to the source MME/SGSN to indicate the handover 
has been successfully finished. 

Table 7.3.3-1 specifies the presence requirements and conditions of the IBs in the message. 

Table 7.3.3-1 : Information Elements in a Forward Relocation Complete Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Indication Flags 


C 


This IE shall be included if any of the flags are set to 1 . 
Idle mode Signalling Reduction Activation Indication: This 
flag shall be set to 1 if the message is used for inter RAT 
handover and the UE has ISR capability. This flag is set to 
indicate to the source MME/SGSN whether it shall 
maintain the UE's context and whether it shall activate ISR. 


Indication 





Private Extension 







Private Extension 


vs 



7.3.4 Forward Relocation Complete Acknowledge 

A Forward Relocation Complete Acknowledge message shall be sent as a response to Forward Relocation Complete 
Notification during inter eNodeB handover with MME relocation procedure, SRNS Relocation with SGSN change 
procedures using S4 or Inter RAT Handover with MME/S4 SGSN interaction procedures. 
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Table 7.3.4-1 specifies the presence requirements and conditions of the lEs in the message. 
Possible Cause values are: 

"Request accepted". 

"Request rejected" 
- "System failure". 

"Invalid message format". 

"Mandatory IE incorrect". 

"Conditional IE missing". 

Table 7.3.4-1 : Information Elements in a Forward Relocation Complete Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 







Recovery 





Private Extension 







Private Extension 


vs 



7.3.5 Context Request 



The new MME/SGSN shall send the Context Request message to the old MME/SGSN on S3/S16/S10 interface as a 
part of TAU/RAU procedure to get the MM and EPS bearer Contexts for the UE. 

If the sending/new node is a MME, it shall include in the Context Request message: 

the GUTI IE and Complete TAU Request Message IE if the GUTI received from UE indicates the old node is a 
MME. 

the RAI IE and the P-TMSI IE, which are derived from the GUTI received from UE, and the P-TMSI Signature 
that was received intact from the UE, if the GUTI indicates the old node is an SGSN. 

If the sending/new node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Context 
Request message. If the receiving/old node is an MME, it shall construct GUTI according to the RAI IE, P-TMSI IE 
and P-TMSI Signature IE (see the mapping relationship between RAI, P-TMSI, P-TMSI signature and GUTI defined in 
3GPP TS23.003 [2]), and find UE context via this GUTI. 

The new MME differentiates the type of the old node from the most significant bit of the MME group id in GUTI. The 
value indicates that the old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; and 
the value 1 indicates the old node is a MME, the new MME include GUTI IE and Complete TAU Request Message IE 
in the Context Request message. The Mapping between temporary and area identities is defined in 3GPP TS 23.003 [2]. 

NOTE: In networks where this definition is not applied (e.g. in networks already configured with LAC with the 
most significant bit set to 1 before LTE deployment), specific network implementations still satisfying 
3GPP standard interfaces can be used to distinguish the node type. See subclause 2.8.2.2.2 of 3GPP TS 
23.003 [2]. 

The Target PLMN ID IE shall be used in old SGSN/MME in order to decide whether un-used authentication vectors to 
be distributed to new SGSN/MME or not. Distribution and use of authentication vectors between different serving 
network domains are specified in 3GPP TS 33.401 [12]. 

Table 7.3.5-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.5-1 : Information Elements in a Context Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


C 


IMSI shall be included if the UE has been successfully 
authenticated. 


IMSI 





GUTI 


C 


The New IVIME shall include this IE over S10 interface. 


GUTI 





Routeing Area 
Identity(RAI) 


c 


This IE shall be included over S3/S1 6 interface. If the GUTI 
indicates the old node is an SGSN, the new IVIME maps 
this IE from GUTI. 


ULI for RAI 





Packet TMSI(P-TMSl) 


c 


This IE shall be included over S3/S1 6 interface. For the S3 
interface, if sent by the MME, this IE Is derived by the MME 
from the GUTI received from the UE. 


P-TMSI 





P-TMSI Signature 


c 


This IE shall be included over S3/S16 interface if it is 
received from the UE. 


P-TMSI Signature 





Complete TAU 
request message 


c 


The new MME shall include this IE, and the old MME may 
use this IE for integrity check. 


Complete 
Request Message 





S3/S16/S10 Address 
and TEID for Control 
Plane 


c 


This IE specifies the address and the TEID for control 
plane message which is chosen by the new MME/SGSN. 
In case of SGSN pool, the IPv4 or the IPv6 address field 
shall be set to the same value of the Source IP address of 
the IP packet carrying this message, and the relaying 
SGSN shall not change the content of this IE when 
sending it to the old SGSN. 


F-TEID 





UDP Source Port 
Number 


c 


If an SGSN within the same SGSN pool as the old SGSN 
receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
parameter if this IE is not present and relay the message to 
the old SGSN. The old SGSN shall use this UDP port as 
the UDP destination port of the Context Response 
message. 


Port Number 





RAT Type 


c 


The RAT Type indicates the Radio Access Technology 
which is used in the new system. 


RAT Type 





Indication 





This IE may be included if any one of the applicable flags 

is set to 1 . 

Applicable Flags are: 

- The MS Validated indicates that the new system 
has successfully authenticated the UE, or the new 
system has validated the integrity protection of the 
TAU request message. 


Indication 





Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise, the SGSN may include a Hop Counter with a 
value of max-1 , and may relay the message to the old 
SGSN. 


Hop Counter 





Target PLMN ID 


CO 


If available, this IE shall be included in order to allow old 
MME/SGSN to make a judgment whether un-used 
authentication vectors to be distributed or not. 


Serving Network 





Private Extension 







Private Extension 


vs 



7.3.6 Context Response 



A Context Response message shall be sent as a response to a previous Context Request message during TAU/RAU 
procedure. 

Possible Cause values are: 

"Request Accepted" 

- "IMSI not known" 

- "System failure" 
"Mandatory IE incorrect" 
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"Conditional IE missing". 
"Invalid message format" 
- "P-TMSI Signature mismatch" 
"User authentication failed" 
Table 7.3.6-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.3.6-1 : Information Elements in a Context Response 



ETSI TS 129 274 V8.10.0 (2011-06) 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





IMSI 


C 


This IE shall be included if the Cause IE has the value " 
Request Accepted ". 


IMSI 





MME/SGSN UE MM 
Context 


C 


This IE shall be included if the Cause IE has the value " 
Request Accepted ". 


MM Context 





MME/SGSN UE EPS 
PDN Connections 


C 


This IE shall be included if there is at least a PDN 
connection for this UE on the sending MME/SGSN. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of PDN 
Connections. 


PDN Connection 





Sender F-TEID for 
Control Plane 


C 


This IE specifies the address and the TEID for control 
plane message which is chosen by the old MME/SGSN. 


F-TEID 





SGWS11/S4IP 
Address andTEIDfor 
Control Plane 


C 


This IE shall be included if a SGW is being used by the old 
MME/SGSN. 


F-TEID 


1 


SGW node name 


C 


This IE shall be included if the source MME or SGSN has 
the source SGW FQDN. This IE identifies the SGW that 
was used by the old MME/SGSN. 


FQDN 





Indication Flags 


c 


This IE shall be included if any of the flags are set to 1 . 

Idle mode Signalling Reduction Supported Indication: 
This flag shall be set to 1 if the Cause IE value 
indicates "Request accepted" and the old system 
has the ISR capability. 

Change Reporting support indication: 

This flag shall be set to 1 if the Source S4- 
SGSN/MME supports Location Change Reporting 
mechanism. 


Indication 





Trace Information 


c 


This IE shall be included when session trace is active for 
this IMSI/IMEI. 


Trace Information 





HRPD access node 
S101 IP address 


c 


This IE shall be included only if the HRPD pre registration 
was performed at the old MME 


IP-Address 





1XIWSS102IP 
address 


c 


This IE shall be included only if the 1xRTT CS fallback pre 
registration was performed at the old MME 


IP-Address 


1 


Subscribed RFSP 
Index 


CO 


This IE shall be included only during inter-MME/SGSN 
mobility procedures, if the source MME/SGSN receives it 
from an HSS. 


RFSP Index 





RFSP Index in Use 


CO 


This IE shall be included only during inter-MME/SGSN 
mobility procedures, if the source MME/SGSN supports the 
feature. 


RFSP Index 


1 


Private Extension 







Private Extension 


vs 
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Table 7.3.6-2: MME/SGSN UE EPS PDN Connections within Context Response 



Octet 1 


PDN Connection IE Type = 109 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


APN 


M 




APN 





APN Restriction 


C 


This IE denotes the restriction on the combination of types 
of APN for the APN associated with this EPS bearer 
Context. The target MME or SGSN determines the 
IVIaximum APN Restriction using the APN Restriction. 
If available, the source MME/S4 SGSN shall include this 
IE. 


APN Restriction 





Selection IVIode 


CO 


When available, this IE shall be included by the source 
MME/S4-SGSN. 


Selection Mode 





IPv4 Address 


C 


This IE shall not be included if no IPv4 Address is 
assigned. See NOTE 1. 


IP Address 





IPv6 Address 


C 


This IE shall not be included if no IPv6 Address is 
assigned. 


IP Address 


1 


Linked EPS Bearer ID 


M 


This IE identifies the default bearer of the PDN 
Connection. 


EBI 





PGW S5/S8 IP 
Address for Control 
Plane or PMIP 


M 


This IE shall include the TEID in the GTP based S5/S8 
case and the GRE key in the PMIP based S5/S8 case. 


F-TEID 





PGW node name 


C 


This IE shall be included if the source MME or SGSN has 
the PGW FODN. 


FQDN 





Bearer Contexts 


M 


Several lEs with this type and instance values may be 
included as necessary to represent a list of Bearers. 


Bearer Context 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 




AMBR 





Charging 
characteristics 


C 


This IE shall be present if charging characteristics was 
supplied by the HSS to the MME/SGSN as a part of 
subscription information. 


Charging 
characteristics 





Change Reporting 
Action 


C 


This IE shall be included whenever available at the source 
MME/SGSN. 


Change Reporting 
Action 





Indication flags 


CO 


This IE shall be included if any one of the applicable flags 

is set to 1 . 

Applicable flags: 

Subscribed OoS Change Indication: This flag 
shall be set to 1 if the subscribed OoS profile of 
the related active PDN connection has changed in 
the old MME/SGSN when the UE is in ECM-IDLE 
state and ISR is activated. 


Indication 





NOTE 1 : For deferred IPv4 address allocation, if the l\/IME/S4-SGSN receives the PDN address "0.0.0.0" from 
PGW during "eUTRAN Initial Attach", "PDP Context Activation", "UE requested PDN Connectivity", 
then the l\/IME/S4-SGSN shall include this IPv4 address "0.0.0.0". 



The Bearer Context shall be coded as depicted in Table 7.3.6-3. 
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Table 7.3.6-3: Bearer Context within IVIME/SGSN UE EPS PDN Connections within Context Response 



Octet 1 


Bearer Context IE Type = 93 


Octets 2 and 3 


Length = n 


Octet 4 


Sparae and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


EPS Bearer ID 


M 




EBI 





TFT 


C 


This IE shall be present if a TFT is defined for this bearer. 


Bearer TFT 





SGWS1/S4/S12IP 
Address andTEIDfor 
user plane 


M 




F-TEID 





PGW S5/S8 IP 
Address andTEIDfor 
user plane 


C 


This IE shall only be included for GTP based S5/S8. 


F-TEID 


1 


Bearer Level QoS 


M 




Bearer Level QoS 





BSS Container 


CO 


The l\/IME/S4 SGSN shall include the Packet Flow ID, 
Radio Priority, SAPI, PS Handover XID parameters in the 
TAU/RAU/Handover procedure, if available. 


F-Container 





Transaction Identifier 


C 


This IE shall be sent over S3/S10/S16 if the UE supports 
A/Gb and/or lu mode. 


Tl 






7.3.7 Context Acknowledge 



A Context Acknowledge message shall be sent as a response to a previous Context Response message. 
Possible cause values are: 

"Request accepted". 
- "System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"No resources available". 

"Invalid message format". 

"User authentication failed". 
Table 7.3.7-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.7-1 : Information Elements in a Context Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 


None 


Cause 





Indication flags 


C 


This IE may be included if any one of the applicable flags 

is set to 1 . 

Applicable Flags are: 

SGWCI: 

- SGW change indication indicates a new SGW has 
been selected. The old MME/old SGSN marks in its 
context that the information in the GWs and the 
HSS are invalid. 

ISRAI: 

This flag indicates to the old system that it shall 
maintain the UE's contexts. This flag shall be set 
to 1 if the Cause IE value indicates "Request 
accepted" and ISR is activated as specified in 
3GPP TS 23.401 [3]. 

SeeNOTEL 


Indication 





Private Extension 





None 


Private Extension 


vs 


N0TE1 : For tlie Indication Flags, ttie combination (SGWCI, ISRAI) = 1,1 shall be considered an error if 
received. 



7.3.8 Identification Request 



If the UE identifies itself with temporary identity and it has changed SGSN/MME since detach in Attach procedure, the 
new MME/SGSN shall send an Identification Request message to the old SGSN/MME over S3, S16 or SIO interface to 
request IMSI. 

Table 7.3.8-1 specifies the presence requirements and conditions of the lEs in the message. 

If the sending node/new is a MME, it shall include in the Identification Request message: 

the GUTI IE and Complete Attach Request Message IE if the GUTI received from UE indicates the old node is a 
MME. 

the RAI IE and the P-TMSI IE, which was derived from the GUTI received from UE, and the P-TMSI Signature 
that was received intact from the UE, if the GUTI indicates the old node is an SGSN. 

If the sending/new node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Identification 
Request message. If the receiving/old node is an MME, it shall construct GUTI according to the RAI IE, P-TMSI IE 
and P-TMSI Signature IE (see the mapping relationship between RAI, P-TMSI, P-TMSI signature and GUTI defined in 
3GPP TS23.003[2]), and find UE context via this GUTI. 

The new MME differentiates the type of the old node from the most significant bit of the MME group id in GUTI. The 
value indicates that the old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; and 
the value 1 indicates the old node is a MME, the new MME include GUTI IE and Complete Attach Request Message IE 
in the Identification Request message. The Mapping between temporary and area identities is defined in 3GPP TS 
23.003 [2]. 

NOTE: In networks where this definition is not applied (e.g. in networks already configured with LAC with the 
most significant bit set to 1 before LTE deployment), specific network implementations still satisfying 
3GPP standard interfaces can be used to distinguish the node type. See subclause 2.8.2.2.2 of 3GPP TS 
23.003 [2]. 

The GUTI IE shall not coexist with any of the RAI IE, P-TMSI IE and P-TMSI Signature IE in an Identification 
Request message. If this occurs, the receiving node shall return a corresponding cause value in the response message. 

The Target PLMN ID IE shall be used in old SGSN/MME in order to decide whether un-used authentication vectors to 
be distributed to new SGSN/MME or not. Distribution and use of authentication vectors between different serving 
network domains are specified in 3GPP TS 33.401 [12]. 
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Table 7.3.8-1 : Information Elements in an Identification Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


GUTI 


C 


The new MME shall include this IE over S10 interface. 


GUTI 





Routeing Area 
Identity(RAI) 


C 


This IE shall be included over S3/S16 interface, if the GUTI 
received from the UE indicates the old node is an SGSN, 
the new MME maps this IE from GUTI. 


ULI for RAI 





Packet TMSI(P-TMSI) 


c 


This IE shall be included over S3/S1 6 interface. For the S3 
interface, if sent by the MME, this IE is derived by the MME 
from the GUTI received from the UE. 


P-TMSI 





P-TMSI Signature 


c 


This IE shall be included over S3/S16 interface, if it is 
received from the UE. 


P-TMSI Signature 





Complete Attach 
Request Message 


c 


The new MME shall include this IE over S10 interface, and 
the old MME may use this IE for integrity check. 


Complete 
Request Message 





Address for Control 
Plane 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall include the old IP 
address of the received message in this optional 
parameter if this IE is not present and relay the message to 
the old SGSN. 


IP Address 





UDP Source Port 
Number 


c 


If an SGSN within the same SGSN pool as the old SGSN 
receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
parameter if this IE is not present and relay the message to 
the old SGSN. The old SGSN shall use this UDP port as 
the UDP destination port of the Identification Response 
message. 


Port Number 





Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise, the SGSN may include a Hop Counter with a 
value of max-1 , and may relay the message to the old 
SGSN. 


Hop Counter 





Target PLMN ID 


CO 


If available, this IE shall be included in order to allow old 
MME/SGSN to make a judgment whether un-used 
authentication vectors to be distributed or not. 


Serving Network 





Private Extension 





None 


Private Extension 


vs 



7.3.9 Identification Response 



The old SGSN/MME shall send an Identification Response message to the new MME/SGSN as a response to a previous 
Identification Request message over S3/S10/S16 interface. 

Table 7.3.9-1 specifies the presence requirements and conditions of the IBs in the message. 

For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, if an old SGSN within an SGSN pool receives an 
Identification Request message that contains the optional parameter Address for Control Plane, the old SGSN shall use 
this address as destination IP address of the Identification Response message. 

Possible Cause values are: 

"Request accepted" 

"System failure" 

"Mandatory IE incorrect" 

"Conditional IE missing". 

"Invalid Message format" 

"P-TMSI Signature mismatch" 

"User authentication failed" 
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Only the Cause information element shall be included in the response if the Cause contains another value than "Request 
accepted". 

Table 7.3.9-1 : Information Elements in an Identification Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





IMSI 


C 


This IE sliall be included if the Cause contains the value 
"Request accepted". 


IMSI 





MME/SGSN UE MM 
Context 


C 


This IE shall be included if Attach Request is integrity 
protected 


MM Context 





Trace Information 


CO 


This IE shall be included when session trace is active for 
this IMSI/IMEI. 


Trace Information 





Private Extension 







Private Extension 


vs 



7.3.1 Forward Access Context Notification 

A Forward Access Context Notification message shall be sent from the Old SGSN to the New SGSN over the S16 
interface to forward the RNC contexts to the target system, or sent from the Old MME to the New MME over the SIO 
interface to forward the RNC/eNodeB contexts to the target system. 

When the old SGSN receives the RANAP message Forward SRNS Context, the old SGSN shall send a Forward Access 
Context Notification message to the new SGSN. The new SGSN shall forward the message to the target RNC using the 
corresponding RANAP message. 

When the old SGSN receives a BSSGP message PS handover Required and the acknowledged peer-to-peer LLC 
operation is used for the Bearer Context or when "delivery order" is set in the Bearer Context QoS profile, the old 
SGSN shall send a Forward Access Context Notification message with the PDU Number IE to the new SGSN. The new 
SGSN shall forward the message to the target RNC/ target BSS using the corresponding RANAP message only for PS 
handover to lu mode. 

When the old SGSN receives a BSSGP message PS handover Required from source BSS/RNC for PS handover to 
A/Gb mode, the value part of RAB Context IE shall be empty according to its defined minimum length. 

Table 7.3.10-1 specifics the presence requirements and conditions of the lEs in the message. 

Table 7.3.10-1 : Information Elements in a Forward Access Context Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


RAB Contexts 


C 


This IE shall be included for S1 6 only. Several lEs with this 
type and instance values shall be included as necessary to 
represent a list of Bearers. 

For each RAB context in the received RANAP message, 
the old SGSN shall include this IE in the message. 


RAB Context 





Source RNC PDCP 
context Info 


C 


If available, the old SGSN shall include an Source RNC 
PDCP context info in the message. 


Source RNC 

PDCP context 

Info 





PDU Numbers 


c 


This IE only applies to S16. The old SGSN shall include 
this IE in the message if the acknowledged peer-to-peer 
LLC operation is used for the Bearer Context or when 
"delivery order" is set in the Bearer Context QoS profile in 
A/Gb mode to lu//VGb mode PS handover. 


PDU Numbers 





E-UTRAN 

Transparent 

Container 


c 


This IE shall be included over S10 to contain the eNodeB 
Status Transfer Transparent Container IE specified in S1- 
AP. 


F-Container 





Private Extension 







Private Extension 


vs 
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7.3.1 1 Forward Access Context Acknowledge 

A Forward Access Context Acknowledge message shall be sent to the old MME/SGSN as a response to Forward 
Access Context Notification. 

Possible Cause values are: 

"Request Accepted". 

"Mandatory IE incorrect". 

"Conditional IE missing". 

"Invalid message format". 
Table 7. 3. 11-1 specifics the presence requirements and conditions of the lEs in the message. 

Table 7.3.1 1-1 : Information Elements in a Forward Access Context Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


vs 



7.3.12 Detach Notification 

A Detach Notification message shall be sent from an MME to the associated SGSN, or from an SGSN to the associated 
MME as a part of Detach procedure if the ISR is activated between the MME and SGSN for the UE. 

Possible Cause values are: 

"Local Detach". 

"Complete Detach". 

A Detach Notification message shall also be sent from an SGSN to the associated MME as a part of Detach procedure if 
the ISR is activated between the MME and SGSN for the UE. 

Possible Cause values are: 

- "IMSI Detach only". 

"Local Detach" indicates that this detach is local to the MME/SGSN and so the associated SGSN/MME registration 
where the ISR is activated shall not be detached. The MME/SGSN that receives this message including this Cause value 
of "Local Detach" only deactivates the ISR. This Cause value shall be included in the procedures: 

MME/SGSN-initiated Detach Procedure in case of implicit detach. 

"Complete Detach" indicates both the MME registration and the SGSN registration that the ISR is activated for, shall be 
detached. This "Complete Detach" Cause value shall be included in the procedures: 

UE-initiated Detach Procedure. 

MME/SGSN-initiated Detach Procedure in case of explicit detach. 

For the purpose of SGs handling, the SGSN shall include Detach Type in the Detach Notification message for 
"Complete Detach" when the UE is combined IMSI/EPS attached and the ISR is activated. 

Possible Detach Type values are: 

- "PS Detach". 

- "Combined PS/CS Detach". 
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"PS Detach" indicates that the MME shall perform explicit IMSI detach from EPS service as specified in section 5.4, 
3GPP TS 29.1 18 [22]. "Combined PS/CS detach" indicates that the MME shall perform explicit IMSI detach from non- 
EPS service as specified in section 5.5, 3GPP TS 29.118 [22]. 

"IMSI Detach only" indicates that combined IMSI/EPS attached UE initiates IMSI only GPRS detach from non-GPRS 
service as specified in section 4.7.4.1, 3GPP TS 24.008 [5], and both the SGSN/MME registration shall be remained. 
The MME shall perform explicit IMSI detach from non-EPS service for the SGs handling purpose, which is specified in 
section 5.5, 3GPP TS 29. 1 18 [22]. This "IMSI Detach only" Cause value shall be included in the procedures: 

- UE-initiated Detach Procedure for GERAN/UTRAN for "IMSI Detach only". 

Table 7.3.12-1 specifics the presence of the lEs in the message. 

Table 7.3.12-1: information Elements in a Detacli Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Detach Type 


CO 


This IE shall be included by SGSN when the Cause 
indicates "Complete Detach" for the combined IIVISI/EPS 
attached UE. 


Detach Type 





Private Extension 







Private Extension 


vs 



7.3.13 Detach Acknowledge 



A Detach Acknowledge message shall be sent as a response to a Detach Notification message during Detach procedure. 
Possible Cause values are: 

"Request accepted". 

"System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Invalid Message format" 
Table 7.3.13-1 specifics the presence of the lEs in the message. 

Table 7.3.13-1 : Information Elements in a Detach Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Recovery 







Recovery 





Private Extension 







Private Extension 


VS 



7.3.14 Change Notification Request 

3GPP TS 23.060 [4] specifies that if PGW has requested CGI/SAI/RAI Change Reporting and if S4-SGSN supports the 
feature, then S4-SGSN shall send the Change Notification Request message on the S4 interface to the SGW. If SGW 
supports the feature, the SGW forwards the message on the GTP based S5/S8 interface to the PGW as part of location 
dependent charging related procedures. 

The TEID value used in this message shall be zero. 
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Table 7.3.14-1 : Information Element in Change Notification Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





RAT Type 


M 




RAT Type 





User Location 
Information (ULI) 


C 


The SGSN shall include the User Location Information IE if 
the MS is located in a RAT Type of GERAN, UTRAN or 
GAN and shall include the CGI, SAI or RAI in the 
"Geographic Location" field depending on whether the IVIS 
is in a cell, a service or a routing area respectively. 


ULI 





PGW S5/S8 GTP-C 
IP Address 


C 


This IE shall be sent on S4. 


IP Address 





LBI 


CO 


This IE, identifying the PDN connection, shall be sent by 
the SGSN on S4. 

If the SGW receives this IE, it shall forward it to the PGW 
on S5/S8. 


EBI 





Private Extension 





Vendor or operator specific information 


Private Extension 


vs 



7.3.15 Change Notification Response 



The Change Notification Response message may be sent on the S4 interface by the SGW to the SGSN and is sent on the 
S5/S8 interface by the PGW to the SGW as part of location dependent charging related procedures to acknowledge the 
receipt of a Change Notification Request. 

If SGW does not support the feature (see subclause 7.3.14 "Change Notification Request"), SGW may silently discard 
Change Notification Request message from SGSN. If SGSN does not receive Change Notification Response, SGSN 
may either send Change Notification Request to the same SGW next time UE location changes, or not (marking SGW 
as not supporting the feature). 

The Cause value indicates whether or not the Change Notification Request was received correctly. Possible Cause 
values are: 

"Request accepted". 

"Request accepted partially". 

"Request rejected". 

"Invalid message format". 

- "IMSI not known". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Conditional IE missing". 

"System failure". 

The TEID value used in this message shall be zero. 

If the IMSI is unknown for the receiving GTP-C entity, then the message shall be silently discarded and no further 
processing of the lEs shall continue. 

If the SGSN receives Change Notification Response containing a Cause value of "IMSI not known" and CS bit set to 1, 
this indicates that the associated PDN connection does not exist within the PGW. The Change Reporting mechanism 
shall be stopped in the receiving SGSN for all Bearers of the associated PDN connection. The SGSN shall then initiate 
PDN disconnection for that PDN Connection. 

If the PDN Connection associated of the Change Notification Request message received by the SGW does not exist 
within the SGW, the SGW shall return Change Notification Response with the CS bit set to to the SGSN. The Change 
Reporting mechanism shall be stopped in the receiving SGSN for all Bearers of the associated PDN connection, and the 
SGSN shall then locally delete the PDN connection and release all associated resources. 
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If the location Change Reporting mechanism is to be stopped or modified for this subscriber in the SGSN, then the 
PGW shall include the Change Reporting Action IE in the message and shall set the value of the Action field 
appropriately. 

Table 7.3.15-1: Information Element in Change Notification Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





Cause 


M 




Cause 





Change Reporting 
Action 


C 


This IE shall be included with the appropriate Action field If 
the location Change Reporting mechanism is to be started 
or stopped for this subscriber in the SGSN/MME. 


Change Reporting 
Action 





Private Extension 







Private Extension 


vs 



7.3.16 Relocation Cancel Request 

A Relocation Cancel Request message shall be sent from the source MME/SGSN to the target MME/SGSN on 
S3/S10/S16 interface as part of the Inter RAT handover Cancel procedure/Sl Based handover Cancel procedure and on 
the S16 interface as part of the SRNS Relocation Cancel Procedure. Table 7.3.16-1 specifics the presence of the lEs in 
the message. 

Table 7.3.16-1: Information Elements in Relocation Cancel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





RANAP Cause 


C 


This IE shall be present in the case of SRNS relocation 
cancel procedure. It shall contain the cause value received 
from the source RNC in the Relocation Cancel message 
received over the lu interface. 


F-Cause 





Private Extension 







Private Extension 


VS 



7.3.17 Relocation Cancel Response 



A Relocation Cancel Response message shall be sent as a response to a previous Relocation Cancel Request message 
during the Inter RAT handover Cancel procedure/S 1 Based handover Cancel procedure/SRNS Relocation Cancel 
Procedure. 

Possible Cause values are: 

"Request Accepted". 

- "IMSI not known". 

- "System failure". 
"Mandatory IE incorrect". 
"Mandatory IE missing". 
"Conditional IE missing". 
"Invalid message format". 

Table 7.3.17-1 specifics the presence of the lEs in the message. 
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Table 7.3.17-1 : Information Elements in Relocation Cancel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


vs 



7.3.18 Configuration Transfer Tunnel 

A Configuration Transfer Tunnel message shall be used to tunnel eNodeB Configuration Transfer messages from a 
source MME to a target MME over the SIO interface. The purpose of the eNodeB Direct Configuration Transfer is to 
transfer information from an eNodeB to another eNodeB in unacknowledged mode (see 3GPP TS 36.413 [10]). 

Table 7.3.18-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.3.18-1 : Information Elements in a Configuration Transfer Tunnel Message 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


E-UTRAN 

Transparent 

Container 


M 


This IE stiall contain the SON transfer IE. 


F-Container 





Target eNodeB ID 


M 


This IE shall contain the ID of the target eNodeB 


Target 
Identification 






7.3.19 RAN Information Relay 



The RAN Information Relay message shall be sent on S3 interface between SGSN and MME to transfer the RAN 
information received by an SGSN from BSS or RNS (GERAN lu mode) or by an MME from eNodeB. The procedures 
are specified in 3GPP TS 23.401 [3]. 

This message shall also be sent on S16 interface to transfer the RAN information between GERAN or GERAN lu mode 
and UTRAN. 

For handling of protocol errors the RAN Information Relay message is treated as a Response message. 

Table 7.3.19-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.3.19-1: Information Elements in a RAN Information Relay 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


BSS Container 


M 


All information elements from the RIM messages, starting 
from and including the BSSGP "PDU type", shall be 
contained within the BSS Container and forwarded to the 
destination MME/SGSN in the RAN Information Relay 
message. 


F-Container 





RIM Routing Address 


C 


This IE shall be included if the RIM Routing Address 
information is included in the message sent from the 
source RAN node 

This IE identifies the destination RAN node where the RAN 
Information needs to be relayed to. It contains the 
destination RNC Identity when the source is 
E-UTRAN/UTRAN and the target is GERAN lu mode or the 
destination Cell Identity when the source is E- 
UTRAN/UTRAN and the target is GERAN or the 
destination global eNodeB ID when the source is GERAN 
and the target is E-UTRAN. 


Target 
Identification 





Private Extension 





None 


Private Extension 


VS 
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7.4 CS Fallback and SRVCC related messages 
7.4.1 Suspend Notification 

The Suspend Notification message shall be sent on the S 11 interface by the MME to the SGW as part of the IxRTT CS 
fallback procedures in 3GPP TS 23.272 [21]. 

The Suspend Notification message shall be sent on the S3 interface by the SGSN to the MME as part of the SRVCC 
procedures in 3GPP TS 23.216 [38] or the CS fallback from E-UTRAN access to UTRAN/GERAN CS domain access 
related procedures in 3GPP TS 23.272 [21]. 

The Suspend Notification message shall be sent on the S 16 interface as per the inter-SGSN suspend procedures in 3GPP 
TS 23.060 [35]. 

The Suspend Notification message shall be sent on the S16 interface as part of the SRVCC from UTRAN (HSPA) to 
GERAN without DTM support procedure in 3GPP TS 23.216 [38]. 

After receiving a Suspend Notification message from the MME, the SGW should discard packets it receives from the 
PGW for the suspended UE. 

Table 7.4.1-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.4.1-1: Information Element in Suspend Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 


This IE sliall be included only on the S1 1 interface. 


IMSI 





Routeing Area 
Identity(RAI) 


C 


This IE shall be included only on the S3 interface. 


ULI for RAI 





CO 


This IE shall be included on the S16. 


Packet TMSI(P-TMSI) 


c 


This IE shall be included only on the S3 interface. 


P-TMSI 





CO 


This IE shall be included on the S16. 


Private Extension 







Private Extension 


VS 



7.4.2 Suspend Acknowledge 

The Suspend Acknowledge message shall be sent on the SI 1 interface by the SGW to the MME as part of the IxRTT 
CS fallback procedures in 3GPP TS 23.272 [21]. 

The Suspend Acknowledge message shall be sent on the S3 interface by the MME to the SGSN as part of the SRVCC 
procedures in 3GPP TS 23.216 [38] or the CS fallback from E-UTRAN access to UTRAN/GERAN CS domain access 
related procedures in 3GPP TS 23.272 [21]. 

The Suspend Acknowledge message shall be sent on the S16 interface as per the inter-SGSN suspend procedures in 
3GPPTS 23.060 [35]. 

The Suspend Acknowledge message shall be sent on the S16 interface as part of the SRVCC from UTRAN (HSPA) to 
GERAN without DTM support procedure in 3GPP TS 23.216 [38]. 

Possible Cause values are: 

"Request Accepted". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 

"Conditional IE missing". 
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For backward compatibility, if the IMSI IE is missing in the Suspend Notification message that is received on the SI 1 
interface, the cause value "Mandatory IE missing" shall be used. 

Table 7.4.2-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.4.2-1 : Information Element in Suspend Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


vs 



7.4.3 Resume Notification 

The Resume Notification message shall be sent on the S 1 1 interface by the MME to the SGW as part of the resume 
procedure returning from CS fallback to E-UTRAN. 

The Resume Notification message shall also be sent on the S4 interface by the SGSN to the SGW as part of the resume 
procedure returning from SRVCC to HSPA as specified in 3GPP TS 23.216 [38]. 

After receiving a Resume Notification message from the MME/SGSN, the SGW shall forward packets it receives from 
the PGW for the UE. 

Table 7.4.3-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.4.3-1 : Information Element in Resume Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





Private Extension 







Private Extension 


VS 



7.4.4 Resume Acknowledge 

The Resume Acknowledge message shall be sent on the S 1 1 interface by the SGW to the MME as part of the resume 
procedure returning from CS fallback to E-UTRAN. 

The Resume Acknowledge message shall also be sent on the S4 interface by the SGW to the SGSN as part of the 
resume procedure returning from SRVCC to HSPA as specified in 3GPP TS 23.216 [38]. 

Possible Cause values are: 

"Request Accepted". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 
Table 7.4.4-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.4.4-1 : Information Element in Resume Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 
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7.4.5 CS Paging Indication 

The CS Paging Indication shall be sent on the S3 interface by the MME to the associated SGSN when ISR is activated 
as part of mobile terminated CS services. The MME gets the related information from SGsAP-P AGING-REQUEST 
message as specified in 3GPP TS29.1 18 [21]. Table 7.4.5-1 specifies the presence requirements and the conditions of 
the lEs in the message. 

Table 7.4.5-1: Information Element in CS Paging Indication 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





VLR Name 


M 




FQDN 





TMSI 







TMSI 





Location area 
identifier 







ULI 





Global CN-ld 







Global CN-ld 





Channel needed 







Channel needed 





eMLPP Priority 







eMLPP Priority 





Service Indicator 


CO 


This IE shall be sent if the service type for the paging is 
available. 


Service Indicator 





Private Extension 







Private Extension 


vs 



7.4.6 Alert MME Notification 

An Alert MME Notification message shall be sent on the S3 interface by the MME to the associated SGSN as part of an 
SGs Non-EPS alert procedure (see 3GPP TS 29. 11 8 [22]) when ISR is activated, except under the conditions specified 
in 3GPP TS 23.272 [21], to request to receive a notification when any activity from the UE is detected. 

Table 7.4.6-1 specifies the presence requirements and the conditions of the lEs in the message. 
Table 7.4.6-1 : Information Element in Alert MME Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 







Private Extension 


VS 



7.4.7 Alert MME Acknowledge 



An Alert MME Acknowledge message shall be sent as a response to an Alert MME Notification message. 
Possible Cause values are: 

"Request accepted"; 

"Invalid Message format". 

NOTE: An SGSN implemented according to an earlier version of the specification will silently discard the Alert 
MME Notification message. An MME which does not receive an Alert MME Acknowledge message may 
not send further Alert MME Notification message to this SGSN. 

Table 7.4.7-1 specifies the presence requirements and the conditions of the lEs in the message. 

Table 7.4.7-1 : Information Elements in Alert MME Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 
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7.4.8 UE Activity Notification 

A UE Activity Notification message shall be sent on the S3 interface by the SGSN to the associated MME as part of an 
SGs Non-EPS alert procedure (see 3GPP TS 29. 11 8 [22]) when ISR is activated, except under the conditions specified 
in 3GPP TS 23.272 [21], to indicate that activity from a UE has been detected. Table 7.4.8-1 specifies the presence 
requirements and the conditions of the lEs in the message. 

Table 7.4.8-1 : Information Element in UE Activity Notification 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Private Extension 







Private Extension 


VS 



7.4.9 UE Activity Acl^nowledge 



A UE Activity Acknowledge message shall be sent as a response to a UE Activity Notification message. 
Possible Cause values are: 

"Request accepted"; 

"Invalid Message format". 
Table 7.4.9-1 specifics the presence requirements and the conditions of the lEs in the message. 

Table 7.4.9-1 : Information Elements in UE Activity Acknowledge 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 







Private Extension 


VS 



7.5 Non-3GPP access related messages 
7.5.1 Create Forwarding Tunnel Request 

A Create Forwarding Tunnel Request message shall be sent by a MME to a Serving GW as a part of the MME 
configures resources for indirect data forwarding during active handover procedure from E-UTRAN to CDMA 2000 
HRPD access. 

Table 7.5.1-1 specifies the presence requirements and the conditions of the lEs in the message. 

Table 7.5.1-1 : Information Elements in a Create Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


S103PDNData 
Forwarding Info 


M 


The IVIIVIE shall include the forwarding Infomation for all 
PDN connections of the UE requesting data forwarding 
towards the HSGW in the message as S103 PDN Data 
Forwarding Info information elements. For each of those 
PDN Connections, an IE with the same type and instance 
value shall be included. 

The Serving GW shall forward downlink data to the HSGW 
via the GRE tunnel identified by the HSGW Address and 
HSGW GRE Key included in this information element when 
it receives downlink data forwarded from the eNodeB 
belonging to the corresponding EPS bearers of the PDN 
connection. 


S103PDF 





Private Extension 







Private Extension 


VS 
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7.5.2 Create Forwarding Tunnel Response 

A Create Forwarding Tunnel Response message shall be sent by a Serving GW to a MME as a response to a Create 
Forwarding Tunnel Request message. 

Table 7.5.2-1 specifies the presence requirements and the conditions of the lEs in the message. 

The Cause value indicates if Data Forwarding Resources has been created in the Serving GW or not. Data Forwarding 
Resources have not been created in the Serving GW if the Cause differs from "Request accepted". Possible Cause 
values are: 

"Request Accepted". 

"No resources available". 

- "System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Invalid message format". 

Only the Cause IE shall be included in the response if the Cause IE contains another value than "Request accepted". 

Table 7.5.2-1 : Information Elements in a Create Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





S1-UData 
Forwarding Info 


C 


S1-U Data Forwarding Info shall be included in the 
message if the Cause contains the value "Request 
accepted". For each EPS bearer requesting data 
forwarding which is included in the S103 PDN Data 
Forwarding Info fields of corresponding Create Forwarding 
Tunnel Request message, the Serving GW shall assign a 
Serving GW S1-U Address and Serving GW S1-U TEID 
pair and included it in the response message as S1-U Data 
Forwarding Info information element. For each of those 
EPS bearers, an IE with the same type and Instance value 
shall be included. 

The eNodeB shall forward downlink data of the EPS bearer 
to the Serving GW via the GTP-U tunnel identified by the 
Serving GW S1-U Address and Serving GW S1-U TEID. 


S1UDF 





Private Extension 







Private Extension 


vs 



7.6 Reliable Delivery of Signalling IVIessages 

Retransmission requirements in the current subclause do not apply to the Initial messages that do not have Triggered 

messages. 

Reliable delivery in GTPv2 messages is accomplished by retransmission of these messages. A message shall be 
retransmitted if and only if a reply is expected for that message and the reply has not yet been received. There may be 
limits placed on the total number of retransmissions to avoid network overload. 

Initial messages and their Triggered messages, as well as Triggered messages and their Triggered Reply messages are 
matched based on the Sequence Number and the IP address and port rules in subclause 4.2 "Protocol stack". Therefore, 
an Initial message and its Triggered message, as well as a Triggered message and its Triggered Reply message shall 
have the same sequence Number. A retransmitted GTPv2 message (an Initial or a Triggered) has the exact same GTPv2 
message content, including the GTP header, UDP ports, source and destination IP addresses as the originally 
transmitted GTPv2 message. 

For each triplet of local IP address, local UDP port and remote peer's IP address a GTP entity maintains a sending queue 
with signalling messages to be sent to that peer. The message at the front of the queue shall be sent with a Sequence 
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Number, and if the message has an expected reply, it shall be held in a list until a reply is received or until the GTP 
entity has ceased retransmission of that message. The Sequence Number shall be unique for each outstanding Initial 
message sourced from the same IP/UDP endpoint. A node running GTP may have several outstanding messages waiting 
for replies. Not counting retransmissions, a single GTP message with an expected reply shall be answered with a single 
GTP reply, regardless whether it is per UE, per APN, or per bearer 

A piggybacked initial message (such as a Create Bearer Request message or Modify Bearer Request message) shall 
contain a Sequence Number that is assigned by sending GTP entity and the message shall be held in a list until a 
response is received. The response message to a piggybacked initial message may arrive without piggybacking (e.g.. 
Create Bearer Response at PGW). 

The Sequence Number in the GTP header of the triggered response message shall be copied from the respective request 

message. 

If a request message (e.g.. Create Session Request) triggers piggybacking (i.e.. Create Bearer Request piggybacked on 
Create Session Response), re-transmission of the request message shall also trigger piggybacking. A Sequence Number 
used for a Command message and its Triggered messages, as well as respective Triggered Reply message shall be the 
same as in the Command message and shall have the most significant bit set to 1 . This setting of the most significant bit 
of the Sequence Number is done to avoid potential clashes between the Sequence Number selected for a Command 
message, and the Sequence Number selected by a GTPv2 peer for a Request message, which was not triggered by a 
Command message. 

A Sequence Number used for a Request message, which was not triggered by a Command message shall have the most 
significant bit set to 0. 

A timer, denoted T3-RESPONSE, shall be started when a signalling message (for which a reply is expected) is sent. A 
signalling message or the triggered message has probably been lost if a reply has not been received before the T3- 
RESPONSE timer expires. 

Once the T3-RESP0NSE timer expires, the message corresponding to the T3-RESP0NSE timer is then retransmitted if 
the total number of retry attempts is less than N3-REQUESTS times. The expiry of the timer for piggybacked request 
messages shall result in re-transmission of the original IP/UDP packet containing both the triggered response message 
and the piggybacked initial message. T3-RESPONSE timer and N3-REQUESTS counter setting is implementation 
dependent. That is, the timers and counters may be configurable per procedure. Multileg communications (e.g. Create 
Session Requests and Responses) however require longer timer values and possibly a higher number of retransmission 
attempts compared to single leg communication. 

All received GTPv2 messages with an expected reply shall be replied to and all reply messages associated with a certain 
message shall always include the same information. Duplicated reply messages shall be discarded by the receiver unless 
the reply needs a reply. A received reply message without a matching outstanding message that is waiting for a reply 
should be discarded. 

If a GTPv2 node is not successful with the transfer of a non-Echo signalling message, e.g. a Create Bearer Request 
message, it shall inform the upper layer of the unsuccessful transfer so that the controlling upper entity may take the 
necessary measures. 

1.1 Error Handling 

7.7.0 Handling Piggybacked Messages 

For piggybacked initial messages, the following general rule shall apply: the triggered response message carrying the 
piggybacked message shall be processed first, according to the following sections. Subsequently, the piggybacked 
initial message shall be processed independently. If the processing of dedicated bearer activation message results in an 
error, this shall not affect the default bearer establishment. If the default bearer establishment fails, the dedicated bearer 
activation related message shall be discarded. 

7.7.1 Protocol Errors 

A protocol error is defined as a message or an Information Element received from a peer entity with unknown type, or if 
it is unexpected, or if it has an erroneous content. 
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The term silently discarded is used in the following subclauses to mean that the receiving GTP entity's implementation 
shall discard such a message without further processing, or that the receiving GTP entity discards such an IE and 
continues processing the message. The conditions for the receiving GTP entity to silently discard an IE are specified in 
the subsequent subclauses. 

The handling of unknown, unexpected or erroneous GTP messages and lEs shall provide for the forward compatibility 
of GTP. Therefore, the sending GTP entity shall be able to safely include in a message a new conditional-optional or an 
optional IE. Such an IE may also have a new type value. Any legacy receiving GTP entity shall, however, silently 
discard such an IE and continue processing the message. 

If a protocol error is detected by the receiving GTP entity, it should log the event including the erroneous message and 
should include the error in a statistical counter. 

An information element with "Mandatory" in the "Presence requirement" column of a message definition shall always 
be present in that message. 

An information element with "Conditional" in the "Presence requirement" column of a message definition shall be sent 
when the conditions detailed in the "Presence requirement" are met. 

The Version Not Supported Indication message shall be considered as a Triggered message as specified in subclause 
4.2.5 "Messages with GTPv2 defined replies: Classification of Initial and Triggered Messages". 

The receiving GTP entity shall apply the error handling specified in the subsequent subclauses in decreasing priority. 

If the received erroneous message is a reply to an outstanding GTP message, the GTP transaction layer shall stop 
retransmissions and notify the GTP application layer of the error even if the reply is silently discarded. 

7.7.2 Different GTP Versions 

If a GTP entity receives a message of an unsupported GTP version, it shall return a Version Not Supported Indication 
message and discard the received message. 



7.7.3 GTP Message of Invalid Length 



If a GTP entity receives a message, which is too short to contain the respective GTPv2 header, the GTP-PDU shall be 
silently discarded. 

Apart from a piggybacked GTP message, if a GTP entity receives a Request message within an IP/UDP packet of a 
length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity 
should log the error and shall send the Response message with Cause IE value set to "Invalid Length". 

Apart from a piggybacked GTP message, if a GTP entity receives a Response message within an IP/UDP packet of a 
length that is inconsistent with the value specified in the Length field of the GTP header, then the receiving GTP entity 
should log the error and shall silently discard the message. 

If a GTP entity receives two GTP messages (triggered response message and a piggybacked initial message) within an 
IP/UDP packet of a length that is inconsistent with the total length of the two concatenated messages as indicated by 
Length fields of the GTP headers, then the receiving GTP entity should log the error and return an appropriate Response 
message with Cause IE value set to "Invalid overall length of the triggered response message and a piggybacked initial 
message". That is: 

for a Create Session Response message together with a piggybacked Create Bearer Request message, a Create 
Bearer Response message should be returned with the above Cause value. 

for a Create Bearer Response message together with a piggybacked Modify Bearer Request message, a Modify 
Bearer Response message should be returned with the above Cause value. 

7.7.4 Unknown GTP Message 

If a GTP entity receives a message with an unknown Message Type value, it shall silently discard the message. 
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7.7.5 Unexpected GTP Message 



If a GTP entity receives an unexpected initial message (see subclause 4.3 "Protocol stack"), it shall be silently discard 
the message and shall log an error. 

If a GTP entity receives an unexpected triggered message (see subclause 4.3 "Protocol stack"), it shall discard the 
message and may log an error. 



7.7.6 Missing Information Elements 



A GTP entity shall check if all mandatory lEs are present in the received Request message. If one or more mandatory 
information elements are missing, the GTP entity should log the error and shall send a Response message with Cause IE 
value set to "Mandatory IE missing" together with the type and instance of the missing mandatory IE. 

If a GTP entity receives a Response message with Cause IE value set to "Mandatory IE missing", it shall notify its 
upper layer. 

A GTP entity shall check if all mandatory lEs are present in the received Response message. If one or more mandatory 
information elements are missing, the GTP entity shall notify the upper layer and should log the error. 

A GTP entity shall check if conditional information elements are present in the received message, if possible (i.e. if the 
receiving entity has sufficient information available to check if the respective conditions were met). 

When possible, a GTP entity shall check if all conditional lEs are present in the received Request message. If one or 
more conditional information elements are missing, GTP entity should log the error and shall send a Response message 
with Cause IE value set to "Conditional IE missing" together with the type and instance of the missing conditional IE. 

When possible, a GTP entity shall check if all conditional lEs are present in the received Response message. If one or 
more conditional information elements are missing, GTP entity shall notify the upper layer and should log the error. 

If the Indication IE is applicable for the message as a conditional IE and if it is not present, the GTP entity shall not 
reject the message unless there are other reasons to reject the message. 

If the Indication IE is applicable for the message as conditional IE and if it is present with the value of all the applicable 
flags set to "0", the GTP entity shall not reject the message unless there are other reasons to reject the message. 

Absence of an optional information element shall not trigger any of the error handling processes. 



7.7.7 Invalid Length Information Element 



An information element has invalid length when the actual length of the IE is different from the value of the Length 
field in the IE header. 

If a GTP message contains more than one information elements and one or more of them have invalid length, the 
receiving GTP entity can detect which of the lEs have invalid length only in the following cases: 

If the Length value in the IE header is greater than the overall length of the message; 

If the invalid length IE is the last one in the message. 

If a receiving GTP entity detects information element with invalid length in a Request message, it shall send an 
appropriate error response with Cause IE value set to "Invalid length" together with the type and instance of the 
offending IE. 

Other Length field handling cases are specified below: 

If the received value of the Length field and the actual length of the fixed length IE are consistent, but the length 
is greater than that expected by the fixed number of octets, then the extra octets shall be discarded. 

If the received value of the Length field and the actual length of the fixed length IE are consistent, but the length 
is less than that expected by the fixed number of octets, this shall be considered an error, IE shall be discarded 
and if the IE was received as a Mandatory IE or a verifiable Conditional IE in a Request message, an appropriate 
error response with Cause IE value set to "Invalid length" together with the type and instance of the offending IE 
shall be returned to the sender. 
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If the received value of the Length field and the actual length of the extendable length IE are consistent, but the 
length is greater than that expected by the fixed number of octets preceding the extended field(s), then the extra 
unknown octets shall be discarded. 

If the received value of the Length field and the actual length of the extendable length IE are consistent, but the 
length is less than that expected by the fixed number of octets preceding the extended field(s), this shall be 
considered an error, IE shall be discarded and if the IE was received as a Mandatory IE or a verifiable 
Conditional IE in a Request message, an appropriate error response with Cause IE value set to "Invalid length" 
together with the type and instance of the offending IE shall be returned to the sender. 

7.7.8 Semantically incorrect Information Element 

The receiver of a GTP signalling message Request including a mandatory or a verifiable conditional information 
element with a semantically invalid Value shall discard the request, should log the error, and shall send a response with 
Cause set to "Mandatory IE incorrect" together with a type and instance of the offending IE. 

The receiver of a GTP signalling message Response including a mandatory or a verifiable conditional information 
element with a semantically invalid Value shall notify the upper layer that a message with this sequence number has 
been received and should log the error. 

If a GTP entity receives an information element with a value which is shown as reserved, it shall treat that information 
element as invalid and should log the error. If the invalid IE is received in a Request, and it is a mandatory IE or a 
verifiable conditional IE, the GTP entity shall send a response with Cause set to "Mandatory IE incorrect " together with 
a type and instance of the offending IE. 

The principle is: the use of reserved values invokes error handling; the use of spare values can be silently discarded and 
so in the case of lEs with spare values used, processing shall be continued ignoring the spare values. 

The receiver of a GTP signalling message including an optional information element with a Value that is not in the 
range defined for this information element value shall discard this IE, but shall treat the rest of the message as if this IE 
was absent and continue processing. The receiver shall not check the content of an information element field that is 
defined as 'spare". 

All semantically incorrect optional information elements in a GTP signalling message shall be treated as not present in 
the message. 

7.7.9 Unknown or unexpected Information Element 

The receiver of a GTP message including an unexpected information element with known Type value, but with the 
instance value that is not defined for this message shall discard the IE and log an error. The receiver shall process the 

message. 

An information element with a Type value which is defined in section 8.1 of the present specification but whose 
Instance Value is not expected in the received GTP signalling message according to the grammar defined in section 7.1 
to 7.5 and 7.9 of the present specification shall be silently discarded (skipped) and the rest of the message processed as 
if this information element was not present. 

NOTE: An Information Element in an encoded GTPv2 message or grouped IE is identified by the pair of IE Type 
and Instance value. 



7.7.10 Repeated Information Elements 



An Information Element is repeated if there is more than one IE with the same IE Type and Instance in the scope of the 
GTP message (scope of the grouped IE). Such an IE is a member in a list. 

If an information element is repeated in a GTP signalling message in which repetition of the information element is not 
specified, only the contents of the information element appearing first shall be handled and all subsequent repetitions of 
the information element shall be ignored. When repetition of information elements is specified, only the contents of 
specified repeated information elements shall be handled and all subsequent repetitions of the information element shall 
be ignored. 
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7.7.11 TFT Error Handling 



TFT related error handling for EUTRAN is specified in 3GPP TS 24.301 [23] and for UTRAN/GERAN in 3GPP TS 
24.008 [5]. 



7.8 



Path Failure 



Restoration and Recovery procedures are specified generally in 3GPP TS 23.007 [17] and a path failure may initiate 
recovery procedures. 

Path failure is detected only by using Echo Request / Response messages in the following way. A peer's IP address 
specific counter shall be reset each time an Echo Response message is received from that peer's IP address and 
incremented when the T3-RESP0NSE timer expires for an Echo Request message sent to that peer's IP address. The 
path shall be considered to be down if the counter exceeds N3-REQUESTS. In this case, the GTP entity may notify the 
Operation and Maintenance network element. GTP shall also notify the upper layer of the path failure, so that PDN 
connections or PDP contexts associated with this peer's IP address may be deleted. 

7.9 Restoration and Recovery 

Restoration and Recovery procedures are specified in 3GPP TS 23.007 [17]. 

7.9.1 Delete PDN Connection Set Request 

This message may be sent on S5, S8, or Sll interfaces as specified in 3GPP TS 23.007 [17]. 

Table 7.9.1-1 : Information Elements in a Delete PDN Connection Set Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


MME-FQ-CSID 


C 


This IE sliall be included when a MME reports a partial 
fault according to the requirements in 3GPP TS 23.007 
[17]. IVIore than one FQ-GSID may appear. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included when a SGW reports a partial 
fault according to the requirements in 3GPP TS 23.007 
[17]. IVIore than one FQ-CSID may appear. 


FQ-CSID 


1 


PGW-FQ-CSID 


c 


Shall be included when a PGW reports a partial fault. More 
than one FQ-CSID may appear 


FQ-CSID 


2 


Private Extension 





None 


Private Extension 


VS 



TEID of shall be used for the Delete PDN Connection Set Request. 

Only one type of FQ-CSID shall be included in each Delete PDN Connection Set Request, A mix of different types, 
such as SGW-FQ-CSID and PGW-FQ-CSID shall not be used. A combined node, such as a collocated PGW/SGW, 
shall send separate Delete PDN Connection Set Request for the PGW role and one for the SGW role if a partial fault 
impacts more than one role. 

7.9.2 Delete PDN Connection Set Response 

This message is sent as a response to the Delete PDN Connection Set Request. 

Table 7.9.2: Information Elements in a Delete PDN Connection Set Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





Private Extension 


Q 


None 


Private Extension 


VS 



TEID of shall be used for the Delete PDN Connection Set Response. 
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The following Cause values are defined: 

"Request Accepted" 

"Request rejected" 

- "System failure". 

"Mandatory IE incorrect". 

"Conditional IE missing". 

"Invalid message format". 

"Request Accepted" indicates the receiving node was capable of storing a CSID value for each PDN connection for the 
type of node (MME,SGW or PGW) in the Delete PDN Connection Set Request and has marked, or will mark 
immediately, the PDN connections for deletion as per 3GPP TS 23.007 [17]. "Request Accepted" shall be returned even 
if there are no PDN connections that match. 

"Request rejected" shall be used when the receiver of the Delete PDN Connection Set Request is not capable of storing 
at least one CSID value per PDN connection for the type of node (MME, SOW or PGW) received in the Delete PDN 
Connection Set Request. 

The SGW shall respond to the Delete PDN Connection Set Request independently, i.e. without waiting for replies. 

7.9.3 Update PDN Connection Set Request 

The SGW shall send this message to the PGW on S5/S8 according to the requirements in TS 23.007 [17]. 
Table 7.9.X-1 : Information Elements in a Update PDN Connection Set Request 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


MME-FQ-CSID 


C 


This IE sliall be included for MME relocation without SGW 
relocation per 3GPP TS 23.007 [17]. 


FQ-CSID 





SGW-FQ-CSID 


C 


This IE shall be included for MME relocation without SGW 
relocation per 3GPP TS 23.007 [17]. 


FQ-CSID 


1 


Private Extension 





None 


Private Extension 


vs 



7.9.4 Update PDN Connection Set Response 

This message is sent by the PGW to the SGW on S5/S8 in response to the Update PDN Connection Set Request 

message. 

Table 7.9.y: Information Elements in a Update PDN Connection Set Response 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Cause 


M 




Cause 





PGW-FQ-CSID 


C 


This IE shall be included for MME relocation without SGW 
relocation per 3GPP TS 23.007 [17]. 


FQ-CSID 





Private Extension 





None 


Private Extension 


VS 



The following Cause values are defined: 
"Request accepted" 
"Request rejected" 
- "System failure". 

"Mandatory IE missing". 
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"Invalid message format". 

7.10 Fallback to GTPv1 mechanism 

An EPC entity shall assume that each GTP processing node that it is about to communicate with is GTPv2 capable. 
Before the first GTP tunnel is setup for a given UE/node, the EPC node shall always send a version 2 (GTPv2) message 
to a peer node. 

A GTPv2 entity shall fallback to GTPvl only if: 

a "Version Not Supported" message in GTPvl format as specified in 3GPP TS 29.060 [4] is received from the 
peer node; This indicates that the peer GTP entity does not support GTPv2; 

an S4 SGSN receives the Cause code "Fallback to GTPvl" in a GTPv2 Context Response message over S16 
interface. When an UE has activated a PDP context via S4 SGSN to GGSN and inter-SGSN RAU is underway, 
the old S4 SGSN shall include the Cause value "Fallback to GTPvl" in a GTPv2 Context Response message 
over S16 interface. In this case, the new S4 SGSN shall abort the ongoing GTPv2 procedure and send a GTPvl 
"SGSN Context Request" message to the old S4 SGSN. The fallback to GTPvl is performed only for this UE in 
the current procedure. 

Fallback to GTPvl shall not occur on already established GTP tunnels without change of the peer nodes of the 
communication bearer. 

If a GTPv2 entity does not support GTPvl and receives a GTPvl message, it shall silently discard the message. 

7.11 Fallback to GTPvO 

Fallback from GTPv2 to GTPvO shall not be supported. Therefore, GTPv2 entity should not listen to the well-known 
GTPvO port 3386. If GTPv2 entity listens to the GTPvO port, the entity shall silently discard any received GTPvO 

message. 

7.12 Trace Management Messages 
7.12.1 Trace Session Activation 

The Trace Session Activation message shall be sent on SI 1/S4 by the MME/SGSN to the SGW, and on S5/S8 by the 
SGW to the PGW when session trace is activated for a particular IMSI or IMEI for a UE that is attached and active or 
attached and idle. 

Table 7.12.1-1 specifies the presence of the lEs in the message. 

Table 7.12.1-1 : Information Elements in a Trace Session Activation 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


IMSI 


M 




IMSI 





Trace Information 


M 




Trace Information 





ME Identity (MEI) 


C 


The MME shall include the ME Identity (MEI) IE, if 
available. 


MEI 






7.12.2 Trace Session Deactivation 

The Trace Session Deactivation message shall be sent on SI 1/S4 by the MME/SGSN to the SGW, and on S5/S8 by the 
SGW to the PGW when session trace is deactivated for a particular IMSI or IMEI for a UE that is attached and active or 
attached and idle. 

Table 7.12.2-1 specifies the presence of the lEs in the message. 
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Table 7.12.2-1 : Information Elements in a Trace Session Deactivation 



Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


Trace Reference 


M 




Trace Reference 






8 GTP-C Information Elements 

8.1 Information Element Types 

A GTP control plane (signalling) message may contain several information elements. In order to have forward 
compatible type definitions for the GTPv2 information elements, all of them shall be TLIV (Type, Length, Instance, 
Value) coded. GTPv2 information element type values are specified in the Table 8.1-1. The last column of this table 
indicates whether the information element is: 

Fixed Length: the IE has a fixed set of fields, and a fixed number of octets. 

Variable Length: the IE has a fixed set of fields, and has a variable number of octets. 

For example, the last octets may be numbered similar to "5 to (n+4)". In this example, if the value of the length 

field, n, is 0, then the last field is not present. 

Extendable: the IE has a variable number of fields, and has a variable number of octets. 

The last fields are typically specified with the statement: "These octet(s) is/are present only if explicitly 

specified". The legacy receiving entity shall ignore the unknown octets. 

In order to improve the efficiency of troubleshooting, it is recommended that the information elements should be 
arranged in the signalling messages as well as in the grouped lEs, according to the order the information elements are 
listed in the message definition table or grouped IE definition table in section 7. However the receiving entity shall be 
prepared to handle the messages with information elements in any order. 

Within information elements, certain fields may be described as spare. These bits shall be transmitted with the value set 
to 0. To allow for future features, the receiver shall not evaluate these bits. GTPv2-C information elements that have 
similar semantics in GTPvl-C shall be converted into GTPvl-C format, as specified in TS 29.060 [4], before sending 
them to a pre-R8 GSN. 
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Table 8.1-1 : Information Element types for GTPv2 



IE Type value 
(Decimal) 


Information elements 


Comment / Reference 





Reserved 




1 


International Mobile Subscriber Identity (IMSI) 


Variable Length / 8.3 


2 


Cause 


Variable Length / 8.4 


3 


Recovery (Restart Counter) 


Variable Length / 8.5 


4 to 50 


Reserved for SI 01 interface 


See 3GPPTS 29.276 [14] 


51 to 70 


Reserved for Sv interface 


See 3GPPTS 29.280 [15] 


71 


Access Point Name (APN) 


Variable Length / 8.6 


72 


Aggregate Maximum Bit Rate (AMBR) 


Fixed Length / 8.7 


73 


EPS Bearer ID (EBI) 


Extendable / 8.8 


74 


IP Address 


Variable Length / 8.9 


75 


Mobile Equipment Identity (MEI) 


Variable Length/ 8.10 


76 


MSISDN 


Variable Length/ 8.11 


77 


Indication 


Extendable/ 8.12 


78 


Protocol Configuration Options (PCO) 


Variable Length/ 8.13 


79 


PDN Address Allocation (PAA) 


Variable Length/ 8.14 


80 


Bearer Level Quality of Service (Bearer QoS) 


Extendable/ 8.15 


81 


Flow Quality of Service (Flow QoS) 


Extendable/ 8.16 


82 


RAT Type 


Extendable/ 8.17 


83 


Serving Network 


Extendable/ 8.18 


84 


EPS Bearer Level Traffic Flow Template (Bearer TFT) 


Variable Length/ 8.19 


85 


Traffic Aggregation Description (TAD) 


Variable Length / 8.20 


86 


User Location Information (ULI) 


Variable Length / 8.21 


87 


Fully Qualified Tunnel Endpoint Identifier (F-TEID) 


Extendable / 8.22 


88 


TMSI 


Variable Length / 8.23 


89 


Global CN-ld 


Variable Length / 8.24 


90 


SI 03 PDN Data Forwarding Info (S103PDF) 


Variable Length / 8.25 


91 


S1-U Data Forwarding Info (S1UDF) 


Variable Length/ 8.26 


92 


Delay Value 


Extendable / 8.27 


93 


Bearer Context 


Extendable / 8.28 


94 


Charging ID 


Extendable / 8.29 


95 


Charging Characteristics 


Extendable / 8.30 


96 


Trace Information 


Extendable / 8.31 


97 


Bearer Flags 


Extendable / 8.32 


98 


Reserved 




99 


PDN Type 


Extendable / 8.34 


100 


Procedure Transaction ID 


Extendable / 8.35 


101 


DRX Parameter 


Variable Length/ 8.36 


102 


UE Network Capability 


Variable Length / 8.37 


103 


MM Context (GSM Key and Triplets) 


Extendable / 8.38 


104 


MM Context (UMTS Key, Used Cipher and Quintuplets) 


Extendable / 8.38 


105 


MM Context (GSM Key, Used Cipher and Quintuplets) 


Extendable / 8.38 


106 


MM Context (UMTS Key and Quintuplets) 


Extendable / 8.38 


107 


MM Context (EPS Security Context, Quadruplets and Quintuplets) 


Extendable / 8.38 


108 


MM Context (UMTS Key, Quadruplets and Quintuplets) 


Extendable / 8.38 


109 


PDN Connection 


Extendable / 8.39 


110 


PDU Numbers 


Extendable / 8.40 


111 


P-TMSI 


Variable Length / 8.41 


112 


P-TMSI Signature 


Variable Length / 8.42 


113 


Hop Counter 


Extendable / 8.43 


114 


UE Time Zone 


Variable Length / 8.44 


115 


Trace Reference 


Fixed Length / 8.45 


116 


Complete Request Message 


Variable Length / 8.46 


117 


GUTI 


Variable Length / 8.47 


118 


F-Container 


Variable Length / 8.48 


119 


F-Cause 


Variable Length / 8.49 


120 


Selected PLMN ID 


Variable Length / 8.50 


121 


Target Identification 


Variable Length / 8.51 


122 


Reserved 




123 


Packet Flow ID 


Variable Length / 853 


124 


RAB Context 


Fixed Length / 8.54 


125 


Source RNC PDCP Context Info 


Variable Length / 8.55 


126 


UDP Source Port Number 


Extendable / 8.56 


127 


APN Restriction 


Extendable / 8.57 


128 


Selection Mode 


Extendable / 8.58 


129 


Source Identification 


Variable Length / 8.59 


130 


Reserved 




131 


Change Reporting Action 


Variable Length / 8.61 


132 


Fully Qualified PDN Connection Set Identifier (FQ-CSID) 


Variable Length / 8.62 


133 


Channel needed 


Extendable / 8.63 
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IE Type value 
(Decimal) 


Information elements 


Comment / Reference 


134 


eMLPP Priority 


Extendable / 8.64 


135 


Node Type 


Extendable / 8.65 


136 


Fully Qualified Domain Name (FQDN) 


Variable Length / 8.66 


137 


Transaction Identifier (Tl) 


Variable Length / 8.68 


138 


Reserved 




139 


Reserved 




140 


Reserved 




141 


Reserved 




142 


Reserved 




143 


Reserved 




144 


RFSP Index 


Fixed Length / 8.69 


145 


Reserved 




146 


Reserved 




147 


Reserved 




148 


Reserved 




149 


Service indicator 


Fixed Length / 8.70 


150 


Detach Type 


Fixed Length / 8.71 


151 


Reserved 




152 


Reserved 




153 to 254 


Spare. For future use. 


FFS 


255 


Private Extension 


Variable Length / 8.67 



8.2 



Information Element Format 



Figure 8.2-1 depicts the format of an information element. 



Octets 

1 

2to3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = XXX (decimal) 




Length = n 


Spare Instance 


IE specific data or content of a grouped IE 



Figure 8.2-1 : Information Element Format 

An IE has the following mandatory fields: 

Type field: This field indicates the type of Information Element. The valid values of the IE type are defined in 

clause 8.1. 

Length: This field contains the length of the information element excluding the first four octets, which are 
common for all information elements (Type, Length and the contents of octet 4) and is denoted "n" in Figure 8.2- 
1 . For all the length fields, bit 8 of the lowest numbered octet is the most significant bit and bit 1 of the highest 
numbered octet is the least significant bit. 

Instance: This field shall be used to differentiate amongst different parameters in one specific message which use 
the same information element type (see also subclause 6.1.3 "Information Element Instance"). 

An IE is said to be TLIV (Type, Length, Instance, Value) encoded. 

8.3 International Mobile Subscriber Identity (IMSI) 

International Mobile Subscriber Identity (IMSl) is transferred via GTP tunnels. The sending entity copies the value part 
of the IMSl into the Value field of the IMSl IE. IMSl is defined in 3GPP TS 23.003 [2]. 
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Octets 

1 
2 to 3 
4 
5 
6 

n+4 


Bits 
8 7 6 5 4 3 2 1 




Type = 1 (decimal) 




Length = n 


Spare 


Instance 


Number digit 2 


Number digit 1 


Number digit 4 


Number digit 3 






Number digit m 


Number digit m-1 



Figure 8.3-1: IMSI 

Octets 5 to (n+4) represent the IMSI value in international number format as described in ITU-T Rec E.164 [25], 
encoded as TBCD digits, i.e. digits from through 9 are encoded "0000" to "1001". When there is an odd number of 
digits, bits 8 to 5 of the last octet are encoded with the filler "1111". The maximum number of digits is 15. 

8.4 Cause 

Cause IE is coded as depicted in Figure 8.4-1. 



Octets 

1 
2 to 3 
4 
5 
6 
7 

8-9 
10 


Bits 
8 7 6 5 4 3 2 


1 




Type = 2 (decimal) 




Length = n 


Spare Instance 


Cause value 


Spare 


1 CS 


Type of the offending IE 


Length 


Spare Instance 



Figure 8.4-1: Cause 

For PMIP based S5/S8, the SGW/MAG shall do the mapping between GTPv2 Cause IE and respective PMIPv6 IE as 
specified in 3GPP TS 29.275 [26]. 

The following bits within Octet 6 indicate: 

Bits 8 to 2: Spare, for future use and set to zero 

Bit 1 - CS (Cause Source): If this bit is set to 1, it indicates that the corresponding error cause is originated by 
the remote node (i.e., the MME/SGSN to a PGW, or the PGW to a MME/SGSN). This bit is set to to denote 
that the corresponding error cause is originated by the node sending the message. 

The CS should be set to 1 by the SGW when the SGW relay a response message with cause value from the 
MME/SGSN to the PGW or from the PGW to the MME/SGSN. For PMIP based S5/S8, the SGW shall set the 
CS bit to 1 when the SGW/MAG relay a response message with the cause value from the PGW/LMA to the 
MME/SGSN. 

The Cause value shall be included in the response message. In a response message, the Cause value indicates the 
acceptance or the rejection of the corresponding request message. The Cause value shall indicate the explicit reason for 
the rejection. 

If the rejection is due to a mandatory IE or a verifiable conditional IE is faulty or missing, the offending IE shall be 
included within an additional field, as Type and Instance of the offending IE that caused the rejection. The length in the 
Octet 8-9 and spare bits in the Octet 10 shall be set to "0". In this case, the value of "n" shall be "6". Otherwise, the 
value of "n" is equal to "2". 

The Cause may also be included in the request message. In a request message, the Cause value indicates the reason for 
the request. 

"Request accepted" is returned when the GTPv2 entity has accepted a control plane request. 
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"Invalid Reply from remote peer" is used by the SGW for the messages spanning through two interfaces. This cause 
value is returned by the SGW to the MME/SGSN or PGW in a reply message where the corresponding reply message 
on S5/S8 or S11/S4 from the PGW or MME/SGSN is not decoded as valid. 

The usage of "Fallback to GTPvl" is specified in subclause 7.10 "Fallback to GTPvl mechanism". 

The listed cause values for rejection response message descriptions in clause 7 are not meant to be exhaustive lists. 
Therefore a GTPv2 node shall use the most appropriate matching rejection response cause value that is listed in Table 

8.4-1. 
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Table 8.4-1 : Cause values 



Message Type 


Cause value 
(decimal) 


Meaning 







Reserved. Shall not be sent and if received the Cause shall be treated as an 
invalid IE 


Request / Initial 
message 


1 


Reserved 


2 


Local Detach 


3 


Complete Detach 


4 


RAT changed from 3GPP to Non-3GPP 


5 


ISR deactivation 


6 


Error Indication received from RNC/eNodeB 


7 


IIVISI Detach Only 


8 to 15 


Spare. This value range shall be used by Cause values in an initial/request 
message. See NOTE 4. 


Acceptance in a 

Response / 

triggered 

message 


16 


Request accepted 


17 


Request accepted partially 


18 


New PDN type due to network preference 


19 


New PDN type due to single address bearer only 


20 to -63 


Spare. This value range shall be used by Cause values in an acceptance 
response/triggered message 


Rejection in a 
Response / 

triggered 
message. See 

NOTE 1 . 


64 


Context Not Found 


65 


Invalid IVIessage Format 


66 


Version not supported by next peer 


67 


Invalid length 


68 


Service not supported 


69 


IVIandatory IE incorrect 


70 


IVIandatory IE missing 


71 


Shall not be used. See NOTE 2 and NOTE 3. 


72 


System failure 


73 


No resources available 


74 


Semantic error in the TFT operation 


75 


Syntactic error in the TFT operation 


76 


Semantic errors in packet filter(s) 


77 


Syntactic errors in packet filter(s) 


78 


IVIissing or unknown APN 


79 


Shall not be used. See NOTE 2 and NOTE 3. 


80 


GRE key not found 


81 


Relocation failure 


82 


Denied in RAT 


83 


Preferred PDN type not supported 


84 


All dynamic addresses are occupied 


85 


UE context without TFT already activated 


86 


Protocol type not supported 


87 


UE not responding 


88 


UE refuses 


89 


Service denied 


90 


Unable to page UE 


91 


No memory available 


92 


User authentication failed 


93 


APN access denied - no subscription 


94 


Request rejected (reason not specified) 


95 


P-TMSI Signature mismatch 


96 


IIVISI not known 


97 


Semantic error in the TAD operation 


98 


Syntactic error in the TAD operation 


99 


Reserved IVIessage Value Received 


100 


Remote peer not responding 


101 


Collision with network initiated request 


102 


Unable to page UE due to Suspension 


103 


Conditional IE missing 


104 


APN Restriction type Incompatible with currently active PDN connection 


105 


Invalid overall length of the triggered response message and a piggybacked initial 
message 


106 


Data forwarding not supported 


107 


Invalid reply from remote peer 
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108 


Fallback to GTPvl 


109 


NOTE 4. 


110 


NOTE 4. 


111 


NOTE 4. 


112 


Request rejected for a PMIPv6 reason (see 3GPP TS 29.275 [26]). 


113 to 239 


Spare. For future use in a triggered/response message See NOTE 4. 


Request / Initial 
message 


240 to 255 


Reserved for 3GPP Specific PIVIIPv6 Error Codes as defined in 3GPP TS 29.275 
[26] 


NOTE 1 : The listed cause values for rejection in a response/triggered message can be also used for request 

messages if the request message is triggered by a command message. 
NOTE 2: Subclause 7.7.8 "Semantically incorrect Information Element" specifies quite strict handling of the reserved 

values and therefore this table shall not contain any reserved values. 
NOTE 3: This value was used in earlier versions of the spec. If received, it shall be interpreted as unspecified 

rejection cause. 
NOTE 4: This value is or may be used in the newer versions of the spec. If the receiver cannot comprehend the 

value, it shall be interpreted as unspecified rejection cause. 
NOTE 5: This value is or may be used in the newer versions of the spec. If the receiver cannot comprehend the 

value, it shall be interpreted as an unspecified request/initial message cause. 



8.5 Recovery (Restart Counter) 

Recovery IE is coded as depicted in Figure 8.5-1. 

In the first release of GTPv2 spec n = 1. That is, the overall length of the IE is 5 octets. In future releases of the spec 
additional octets may be specified. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 3 (decimal) 




Length = n 


Spare Instance 


Recovery (Restart Counter) 



Figure 8.5-1 : Recovery (Restart Counter) 



8.6 Access Point Name (APN) 



Access Point Name (APN) is transferred via GTP tunnels. The sending entity copies the value part of the APN into the 
Value field of the APN IE. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 71 (decimal) 




Length = n 


Spare Instance 


Access Point Name (APN) 



Figure 8.6-1 : Access Point Name (APN) 

The encoding the APN field follows 3GPP TS 23.003 [2] subclause 9.1. The content of the APN field shall be the full 
APN with both the APN Network Identifier and APN Operator Identifier being present as specified in 3GPP TS 23.003 
[2] subclauses 9.1.1 and 9.1.2, 3GPP TS 23.060 [35] Annex A and 3GPP TS 23.401 [3] subclause 4.3.8.1. 

NOTE: The APN field is not encoded as a dotted string as commonly used in documentation. 

8.7 Aggregate Maximum Bit Rate (AIVIBR) 

Aggregate Maximum Bit Rate (AMBR) is transferred via GTP tunnels. The sending entity copies the value part of the 
AMBR into the Value field of the AMBR (APN- AMBR) IE. 

AMBR is defined in clause 9.9.4.2 of 3GPP TS 24.301 [23], but shall be formatted as shown in Figure 8.7-1 as 
Unsigned32 binary integer values in kbps (1000 bits per second). 
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Octets 

1 
2 to 3 

4 
5 to 8 
9 to 12 


Bits 
8 7 6 5 4 3 2 


1 




Type = 72 (decimal) 




Length = 8 


Spare Instance 


APN-AMBR for uplink 


APN-AMBR for downlink 



Figure 8.7-1 : Aggregate Maximum Bit Rate (AIUIBR) 



8.8 EPS Bearer ID (EBI) 

EPS Bearer ID (EBI) is coded as depicted in Figure 8.8-1. 

In the first release of GTPv2 spec n = 1. That is, the overall length of the IE is 5 octets. In future releases of the spec 
additional octets may be specified and new semantic for the spare bits may be defined. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 73 (decimal) 




Length = n 


Spare 


Instance 


Spare (all bits set to 0) 


EPS Bearer ID (EBI) 


These octet(s) is/are present only if explicitly specified 



Figure 8.8-1 : EPS Bearer ID (EBI) 



8.9 



IP Address 



IP Address is coded as depicted in Figure 8.9-1. The Length field may have only two values (4 or 16) that determine if 
the Value field contains IPv4 or IPv6 address. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 74 (decimal) 




Length = n 


Spare Instance 


IPv4or IPv6 Address 



Figure 8.9-1 : IP address 



8.10 Mobile Equipment Identity (MEI) 

Mobile Equipment Identity (MEI) is coded as depicted in Figure 8.10-1.. MEI is defined in clause 6.2 of 3GPP TS 
23.003 [2]. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 75 (decimal) 




Length = n 


Spare Instance 


Mobile Equipment (IVIE) Identity 



Figure 8.10-1 : Mobile Equipment (ME) Identity (MEI) 

The ME Identity field contains either the IMEI or the IMEISV as defined in clause 6.2 of 3GPP TS 23.003 [2]. It is 
encoded as specified in clause 7.7.53 of 3GPP TS 29.060 [4], beginning with octet 4 of Figure 7.7.53.1. 

The IMEI(SV) digits are encoded using BCD coding where IMEI is 15 BCD digits and IMEISV is 16 BCD digits. For 
IMEI, bits 5 to 8 of the last octet shall be filled with an end mark coded as '1111'. 
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8.11 MSISDN 

MSISDN is transferred via GTP tunnels. The sending entity copies the value part of the MSISDN into the Value field of 
the MSISDN IE. MSISDN is defined in 3GPP TS 23.003 [2]. 



Octets 

1 
2 to 3 
4 
5 
6 

n+4 


Bits 
8 7 6 5 4 3 2 1 




Type = 76 (decimal) 




Length = n 


Spare 


Instance 


Number digit 2 


Number digit 1 


Number digit 4 


Number digit 3 






Number digit m 


Number digit m-1 



Figure 8.11-1: MSISDN 

Octets 5 to (n+4) represent the MSISDN value is in international number format as described in ITU-T Rec E.164 [25] 
and 3GPP TS 29.002 [37]. MSISDN value contains only the actual MSISDN number (does not contain the "nature of 
address indicator" octet, which indicates "international number" as in 3GPP TS 29.002 [37]) and is encoded as TBCD 
digits, i.e. digits from through 9 are encoded "0000" to "1001". When there is an odd number of digits, bits 8 to 5 of 
the last octet are encoded with the filler "1111". 



8.12 Indication 

Indication is coded as depicted in Figure 8.12-1. 



Octets 

1 

2 to 3 

4 

5 

6 

7 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 77 (decimal) 




Length = n 


Spare 


Instance 


DAF 


DTF 


HI 


DFI 


01 


ISRSI 


ISRAI 


SGW 
CI 


SQCI 


Spare 


CFSI 


CRSI 


P 


PT 


SI 


MSV 


These octet(s) is/are present only if explicitly specified 



Figure 8.12-1 : Indication 

For each message the applicable flags of the Indication IE shall be clearly specified in the individual message sub 
clause. The remaining flags of the Indication IE not so indicated shall be discarded by the receiver. 

The receiver shall consider the value of the applicable flags as "0", if the Indication IE is applicable for the message but 
not included in the message by the sender. 

The following bits within Octet 5 shall indicate: 

Bit 8 - DAF (Dual Address Bearer Flag): This bit shall be set when the UE requests PDN type IPv4v6 and all 
SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is 
determined based on node pre-configuration by the operator.. 

- Bit 7 - DTF (Direct Tunnel Flag): This bit shall be set when the UE is in UTRAN/GERAN network and Direct 
Tunnel is selected 

Bit 6 - HI (Handover Indication): If this bit is set to 1, it shall indicate that a UE handover from a non-3GPP 
access to a 3GPP access system. This bit is applicable during the E-UTRAN Initial Attach procedure or during 
the UE requested PDN connectivity procedure. 

Bit 5 - DFI (Direct Forwarding Indication): If this bit is set to 1, it shall indicate that the direct forwarding 
between the source eNodeB and the target eNodeB during the S 1 based handover procedure is applied. 

- Bit 4 - OI (Operation Indication): 
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If this bit is set to 1, it shall denote that the receiving SGW of a "Create Session Request" shall send a Modify 
Bearer Request immediately to the PGW. This allows the SGW to differentiate if the "Create Session 
Request" received on S4/S1 1 interface belongs to a TAU/RAU with an SGW relocation (OI = 1), or X2- 
based handover with SGW relocation (OI = 1) or Sl-based handover with SGW relocation (OI = 0). 

It shall be set to 1 on S4/S 1 1 interface if the SGW needs to forward the Delete Session Request message to 
PGW. 

Bit 3 - ISRSI (Idle mode Signalling Reduction Supported Indication): If this is set to 1, it shall indicate that the 
old/source SGSN/MME is capable to activate ISR. 

Bit 2 - ISRAI (Idle mode Signalling Reduction Activation Indication): If this bit is set to 1, it shall indicate that 
the ISR is established between the MME and the S4 SGSN during a TAU/RAU without an SGW change 
procedure or during an Inter RAT handover without an SGW change procedure. The SGW shall retain the 
resources for the other CN node that has its bearer resources on the SGW reserved. The old/source SGSN/MME 
shall maintain the UE's contexts and activate ISR. 

- Bit 1 - SGWCI (SGW Change Indication): If this bit is set to 1, it shall indicate that the target MME/SGSN has 
selected a new SGW during a TAU/RAU or handover with an SGW change procedure. 

The following bits within Octet 6 shall indicate: 

Bit 8 - SQCI (Subscribed QoS Change Indication): If this bit is set to 1, it indicates that the subscribed QoS 
profile of the related PDN connection has changed in the old MME/SGSN when the UE is in ECM-IDLE state 
and ISR is activated. The new MME/SGSN shall trigger the Subscribed QoS Modification procedure. See 3GPP 
TS 23.401 [3], clause 5.3.9.2. 

Bit 7 - Spare, for future use and set to zero. 

Bit 6 - CFSI (Change F-TEID support indication): if this bit is set to 1, it indicates that the SGW can change the 
assigned GTP-U F-TEID in the current procedure. The MME/SGSN shall include this flag in the Modify Bearer 
Request message sent to the SGW in the Idle state UE initiated TAU/RAU procedure. The SGW shall include 
the new F-TEID in the Modify Bearer Response message if the CFSI flag is received in the corresponding 
Request message and the SGW needs to modify the GTP-U F-TEID. 

- Bit 5 - CRSI (Change Reporting support indication): if this bit is set to 1, it indicates that the MME/S4 SGSN 
supporting Location Change Reporting mechanism. 

Bit 4 - PS (Piggybacking Supported). This bit denotes whether the MME/SGW support piggybacking feature as 
described in Annex F of 3GPP TS 23.401 [3]. If set to 1, it indicates that the node is capable of processing two 
different GTP-C messages appearing back to back in a single UDP payload. 

Bit 3 - PT (Protocol Type) If this bit set to 1, it shall indicate that the protocol type for the S5/S8 interface is 
PMIP; this bit is set to to indicate that the protocol type for the S5/S8 interface is GTP. 

Bit 2 - SI (Scope Indication): If this bit is set to 1, it indicates that all bearer resources of the UE shall be 
released by the SGW. This flag is set in messages during TAU/RAU/Handover/SRNS Relocation Cancel Using 
S4/Inter RAT handover Cancel procedure with SGW change/Sl Based handover Cancel procedure with SGW 
change. 

- Bit 1 - MSV (MS Vahdated): If this bit is set to 1, it shall indicate that the new MME/SGSN has successfully 
authenticated the UE. 

8.13 Protocol Configuration Options (PCO) 

Protocol Configuration Options (PCO) is transferred via GTP tunnels. The sending entity copies the value part of the 
PCO into the Value field of the PCO IE. The detailed coding of the PCO field from octets 5 to (nH-4) shall be specified 
as per clause 10.5.6.3 of 3GPP TS 24.008 [5], starting with octet 3. 
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Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 78 (decimal) 




Length = n 


Spare Instance 


Protocol Configuration Options (PCO) 



Figure 8.13-1 : Protocol Configuration Options (PCO) 



8.14 PDN Address Allocation (PAA) 

The PDN Address Allocation is coded as depicted in Figure 8.14-1. 
NOTE: In Rel 8, Prefix length has a fixed value of /64. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 79 (decimal) 




Length = n 


Spare Instance 


Spare | PDN Type 


PDN Address and Prefix 



Figure 8.14-1 : PDN Address Allocation (PAA) 



Table 8.14-1 : PDN Address Allocation 



PDN type value (octet 5) 


Bits 




3 2 1 




1 


IPv4 


1 


IPv6 


1 1 


IPv4v6 



Bits 8-4 of octet 5 are spare and shall be coded as zero. 

PDN Address and Prefix (octet 6 to n+4) 

If PDN type value indicates IPv4, an IPv4 address is present in the PDN Address and 
Prefix from octet 6 to octet 9. Bit 8 of octet 6 represents the most significant bit of the 
IPv4 address and bit 1 of octet 9 the least significant bit. 

If PDN type value indicates IPv6, octet 6 contains the IPv6 Prefix Length. Octets 7 
through 22 contain an IPv6 Prefix and Interface Identifier. Bit 8 of octet 7 represents 
the most significant bit of the IPv6 Prefix and Interface Identifier and bit 1 of octet 22 
the least significant bit. 

If PDN type value indicates IPv4v6, octet 6 contains the IPv6 Prefix Length. Octets 7 
through 22 contain an IPv6 Prefix and Interface Identifier. Bit 8 of octet 7 represents 
the most significant bit of the IPv6 Prefix and Interface Identifier and bit 1 of octet 22 
the least significant bit. Octets 23 through 26 contain an IPv4 address. Bit 8 of octet 23 
represents the most significant bit of the IPv4 address and bit 1 of octet 26 the least 
significant bit. 



8.1 5 Bearer Quality of Service (Bearer QoS) 

Bearer Quality of Service (Bearer QoS) is transferred via GTP tunnels. The sending entity copies the value part of the 
Bearer 1 QoS into the Value field of the Bearer QoS IE. 
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Octets 

1 
2-3 

4 

5 

6 
7 to 11 
12to16 
17to21 
22 to 26 
27 to (n-i-4) 


8 


Bits 
7 6 5 4 3 2 1 




Type = 80 (decimal) 




Length = n 


Spare Instance 


Spare 


PCI 1 PL 1 Spare! PVI 


Label (QCI) 


Maximum bit rate for uplink 


Maximum bit rate for downlink 


Guaranteed bit rate for uplink 


Guaranteed bit rate for downlink 


These octet(s) is/are present only if explicitly specified 



Figure 8.15-1 : Bearer Level Quality of Service (Bearer QoS) 

Octet 5 represents the Allocation/Retention Priority (ARP) parameter. The meaning and value range of the parameters 
within the ARP are defined in 3GPP TS 29.212 [29]. The bits within the ARP octet are: 

- Bit 1 - PVI (Pre-emption Vulnerability): See 3GPP TS 29.212[29], clause 5.3.47 Pre-emption- Vulnerability 
AVP. 

Bit 2 - spare 

- Bits 3 to 6 - PL (Priority Level): See 3GPP TS 29.212[29], clause 5.3.45 ARP-Value AVP. PL encodes each 
priority level defined for the ARP-Value AVP as the binary value of the priority level. 

- Bit 7 - PCI (Pre-emption Capability): See 3GPP TS 29.212[29], clause 5.3.46 Pre-emption-CapabiUty AVP. 

Bit 8 - spare. 

QCI, Maximum bit rate for uplink, Maximum bit rate for downlink. Guaranteed bit rate for uplink and Guaranteed bit 
rate for downlink are specified in 3GPP TS 36.413 [10] 

The MBR and GBR are encoded as kilobits per second (1 kbps = 1000 bps). For non-GBR bearers, both the UL/DL 
MBR and GBR should be set to zero. 

NOTE: The encoding in 3GPP TS 24.301 [23] is different from the encoding here. 

8.1 6 Flow Quality of Service (Flow QoS) 

Flow Quality of Service (Flow QoS) is transferred via GTP tunnels. The sending entity copies the value part of the Flow 
QoS into the Value field of the Flow QoS IE. 



Octets 

1 

2 to 3 

4 

5 

6 to 10 

11 to 15 

16 to 20 

21 to 25 

26 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 81 (decimal) 




Length = n 


Spare Instance 


Label (QCI) 


Maximum bit rate for uplink 


Maximum bit rate for downlink 


Guaranteed bit rate for uplink 


Guaranteed bit rate for downlink 


These octet(s) is/are present only if explicitly specified 



Figure 8.16-1 : Flow Quality of Service (Flow QoS) 

QCI, Maximum bit rate for uplink. Maximum bit rate for downlink. Guaranteed bit rate for uplink and Guaranteed bit 
rate for downlink are specified in 3GPP TS 36.413 [10]. 

The MBR and GBR are encoded as kilobits per second (1 kbps = 1000 bps). For non-GBR bearers, both the UL/DL 
MBR and GBR should be set to zero. 

NOTE: The encoding in 3GPP TS 24.301 [23] is different from the encoding here. 
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8.17 RAT Type 

RAT Type is coded as depicted in Figure 8.17-1. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 82 (decimal) 




Length = 1 


Spare Instance 


RAT Type 


These octet(s) is/are present only if explicitly specified 



Figure 8.17-1 : RAT Type 
Table 8.17-1 : RAT Type values 



RAT Types 


Values (Decimal) 


<reserved> 





UTRAN 


1 


GERAN 


2 


WLAN 


3 


GAN 


4 


HSPA Evolution 


5 


EUTRAN 


6 


<spare> 


7-255 



8.18 Serving Network 

Serving Network is coded as depicted in Figure 8.18-1. 



Octets 

1 
2 to 3 
4 
5 
6 
7 
8 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 83 (decimal) 




Length = n 


Spare 


Instance 


MCC digit 2 


MCC digit 1 


MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


These octet(s) is/are present only if explicitly specified 



Figure 8.18-1 : Serving Network 

If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111". 

8.1 9 EPS Bearer Level Traffic Flow Template (Bearer TFT) 

EPS Bearer Level Traffic Flow Template (Bearer TFT) is transferred via GTP tunnels. The sending entity copies the 
value part of the EPS Bearer Level TFT into the Value field of the EPS Bearer Level TFT IE. The detailed coding of the 
EPS Bearer Level TFT IE is specified in 3GPP TS 24.008 [5], clause 10.5.6.12, beginning with octet 3. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 84 (decimal) 




Length = n 


Spare Instance 


EPS Bearer Level Traffic Flow Template (TFT) 



Figure 8.19-1 : EPS Bearer Level Traffic Flow Template (Bearer TFT) 
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8.20 Traffic Aggregate Description (TAD) 

The Traffic Aggregate Description IE is coded as depicted in Figure 8.20-1. The detailed coding of Traffic Aggregate 
Description is specified in 3GPP TS 24.008 [5] , clause 10.5.6.12, beginning with octet 3.. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 85 (Decimal) 




Length = n 


Spare Instance 


Traffic Aggregate Description 



Figure 8.20-1 Traffic Aggregate Description 



8.21 User Location Information (ULI) 



User Location Information (ULI) is a variable length IE that is coded as depicted in Figure 8.21-1. The CGI, SAI, RAI, 
TAI, ECGI and LAI identity types are defined in 3GPP TS 23.003 [2]. 



Octets 

1 
2 to 3 

4 

5 
a to a+6 
b to b+6 
c to c+6 
d to d+4 
e to e+6 
f to f+4 
g to (n+4) 


Bits 
8 7 6 5 4 


3 2 1 




Type = 86 (decimal) 




Length = n 


Spare 


Instance 


Spare | LAI | ECGI 


TAI 


RAI 1 SAI 1 CGI 


CGI 


SAI 


RAI 


TAI 


ECGI 


LAI 


These octet(s) is/are present only 


if explicitly specified 



Figure 8.21-1: User Location Information 

The ULI IE shall contain only one identity of the same type (e.g. more than one CGI cannot be included), but ULI IE 
may contain more than one identity of a different type (e.g. ECGI and TAI). The flags LAI, ECGI, TAI, RAI, SAI and 
CGI in octet 5 indicate if the corresponding type shall be present in a respective field or not. If one of these flags is set 
to "0", the corresponding field shall not be present at all. If more than one identity of different type is present, then they 
shall be sorted in the following order: CGI, SAI, RAI, TAI, ECGI, LAI. 

The following subclauses specify the coding of the fields representing different identities. 

For each identity, if an Administration decides to include only two digits in the MNC, then "MNC digit 3" field of 
corresponding location shall be coded as " 1 1 11". 

8.21.1 CGI field 

The coding of CGI (Cell Global Identifier) is depicted in Figure 8.21.1-1. Only zero or one CGI field shall be present in 
ULI IE. 



Octets 

a 

a+1 

a+2 
a+3 to a+4 
a+5 to a+6 


Bits 
8 7 6 5 4 3 2 1 




IVICC digit 2 


MCC digit 1 




MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Location Area Code (LAC) 


Cell Identity (CI) 



Figure 8.21.1-1: CGI field 
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The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet a+3 is the most significant bit and bit 1 of Octet a+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

The Cell Identity (CI) consists of 2 octets. Bit 8 of Octet a+5 is the most significant bit and bit 1 of Octet a+6 the least 
significant bit. The coding of the cell identity is the responsibility of each administration. Coding using full hexadecimal 
representation shall be used. 

8.21.2 SAI field 

The coding of SAI (Service Area Identifier) is depicted in Figure 8.21.2-1. Only zero or one SAI field shall be present 
in ULI IE. 



Octets 

b 

b+1 

b+2 
b+3 to b+4 
b+5 to b+6 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 2 


IVICC digit 1 




MNCdigit3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Looation Area Code (LAC) 


Servioe Area Code (SAC) 




Figure 8.21 .2-1: 


SAI field 





The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet b+3 is the most significant bit and bit 1 of Octet b+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

The Service Area Code (SAC) consists of 2 octets. Bit 8 of Octet b+5 is the most significant bit and bit 1 of Octet b+6 
the least significant bit. The SAC is defined by the operator. See 3GPP TS 23.003 [2] section 12.5 for more information. 

8.21.3 RAI field 

The coding of RAI (Routing Area Identity) is depicted in Figure 8.2L3-L Only zero or one RAI field shall be present in 
ULI IE. 



Octets 


0+1 

0+2 
0+3 to 0+4 
0+5 to 0+6 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 2 


MCC digit 1 




MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Looation Area Code (LAC) 


Routing Area Code (RAC) 




Figure 8.21 .3-1: 


RAI field 





The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet c+3 is the most significant bit and bit 1 of Octet c+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

The Routing Area Code (RAC) consists of 2 octets. Only Octet c+5 contains the RAC. Octet c+6 is coded as all I's 
(11 11 11 11). The RAC is defined by the operator. 

8.21.4 TAI field 

The coding of TAI (Tracking Area Identity) is depicted in Figure 8.21.4-1. Only zero or one TAI field shall be present 
in ULI IE. 
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Octets 


Bits 
8 7 6 5 4 3 2 1 




d 

d+1 

d+2 

d+3 to d+4 


MCC digit 2 


IVICC digit 1 




MNC digit 3 


IVICC digit 3 


MNCdigit2 


IVINC digit 1 


Tracl<ing Area Code (TAG) 



Figure 8.21 .4-1 :TAI 

The Tracking Area Code (TAC) consists of 2 octets. Bit 8 of Octet d+3 is the most significant bit and bit 1 of Octet d+4 
the least significant bit. The coding of the tracking area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

8.21.5 ECGI field 

The coding of ECGI (E-UTRAN Cell Global Identifier) is depicted in Figure 8.21.5-1. Only zero or one ECGI field 
shall be present in ULI IE. 



Octets 

e 

e+1 

e+2 

e+3 

e+4 to e+6 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 2 


MCC digit 1 




MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Spare 


ECl 


ECl (E-UTRAN Cell Identifier) 



Figure 8.21 .5-1: ECGI field 

The E-UTRAN Cell Identifier (ECl) consists of 28 bits. The ECl field shall start with Bit 4 of octet e+3, which is the 
most significant bit. Bit 1 of Octet e+6 is the least significant bit. The coding of the E-UTRAN cell identifier is the 
responsibility of each administration. Coding using full hexadecimal representation shall be used. 

8.21.6 LAI field 

The coding of LAI (Location Area Identifier) is depicted in Figure 8.21.6-1. 



Octets 

f 

f+1 

f+2 

f+3 to f+4 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 2 


MCC digit 1 




MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Location Area Code (LAC) 



Figure 8.21 .6-1: LAI field 

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet f+3 is the most significant bit and bit 1 of Octet f+4 
the least significant bit. The coding of the location area code is the responsibility of each administration. Coding using 
full hexadecimal representation shall be used. 

8.22 Fully Qualified TEID (F-TEID) 

Fully Qualified Tunnel Endpoint Identifier (F-TEID) is coded as depicted in Figure 8.22-1. 
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Octets 

1 

2to3 

4 

5 

6 to 9 

m to (m+3) 

pto (p+15) 

k to (n+4) 


8 


Bits 
7 6 5 4 3 2 1 




Type = 87 (decimal) 




Length = n 


Spare Instance 


V4 


V6 Spare Interface type 


TElD/GREKey 


IPv4 address 


IPv6 address 


These octet(s) is/are present only if explicitly specified 



Figure 8.22-1 : Fully Qualified Tunnel Endpoint Identifier (F-TEID) 

The following flags are coded within Octet 5: 

Bit 8 - V4: If this bit is set to "1", then IPv4 address field exists in the F-TEID, otherwise the IPv4 address field 
is not present at all. 

Bit 7 - V6: If this bit is set to "1", then IPv6 address field exists in the F-TEID, otherwise the IPv6 address field 
is not present at all. 

At least one of V4 and V6 shall be set to "1", and both may be set to "1". 

Bit 6 - Spare, shall be set to zero by the sender and ignored by the receiver. 

Bit 5 to Bit 1 - Interface Type: This 5 bit wide integer can take the following values representing interface type 
and endpoint: 

0: S 1 -U eNodeB GTP-U interface 

1 : S 1 -U SOW GTP-U interface 

2: S 12 RNC GTP-U interface 

3: S 12 SGW GTP-U interface 

4: S5/S8 SGW GTP-U interface 

5 : S5/S 8 PGW GTP-U interface 

6: S5/S8 SGW GTP-C interface 

7: S5/S8 PGW GTP-C interface 

8: S5/S8 SGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and since alternate CoA is 
not used the control plane and user plane addresses are the same for PMIPv6) 

9: S5/S8 PGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and the control plane and 
user plane addresses are the same for PMIPv6) 

10: Sll MME GTP-C interface 

1 1 : S 1 1/S4 SGW GTP-C interface 

12: SIO MME GTP-C interface 

13: S3 MME GTP-C interface 

14: S3 SGSN GTP-C interface 

15: S4 SGSN GTP-U interface 

16: S4 SGW GTP-U interface 

17: S4 SGSN GTP-C interface 

18: S16 SGSN GTP-C interface 
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19: eNodeB GTP-U interface for DL data forwarding 

20: eNodeB GTP-U interface for UL data forwarding 

21: RNC GTP-U interface for data forwarding 

22: SGSN GTP-U interface for data forwarding 

23: SGW GTP-U interface for DL data forwarding 

24: Reserved 

25: Reserved 

26: Reserved 

27: Reserved 

28: SGW GTP-U interface for UL data forwarding 

Other values of "Interface Type" are spare and reserved for future use. 

Octet 6 to 9 (TEID/GRE field) represent either a TEID or a GRE key. If both IPv4 and IPv6 addresses are present in F- 
TEID IE, then the TEID value shall be shared by both addresses. 

Octets "m to (nn-3)" and/or "p to (pH-15)" (IPv4 address / IPv6 address fields), if present, contain respective address 
values. 

8.23 TMSI 

The TMSI, unambiguously associated with a given UE and Location area, is given by: 



Octets 

1 

2 to 3 

4 

5 to {n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 88 (decimal) 




Length = n 


Spare Instance 


TMSI 
The TMSI is defined in 3GPP TS 23.003 [2]. 



Figure 8.23-1 : TMSI 



8.24 Global CN-ld 



The Global CN-ld is coded as depicted in Figure 8.24-1. 



Octets 

1 
2 to 3 
4 
5 
6 
7 
8 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 89 (decimal) 




Length = n 


Spare 


Instance 


MCC digit 2 


MCC digit 1 


MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


CN-ld 
The CN-ld is defined in 3GPP TS 23.003 [2]. 



Figure 8.24-1 : Global CN-ld 

If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111". 
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8.25 S1 03 PDN Data Forwarding Info (S1 03PDF) 

The HSGW Address and GRE Key identify a GRE Tunnel towards a HSGW over SI 03 interface for a specific PDN 
connection of the UE. The EPS Bearer IDs specify the EPS Bearers which require data forwarding that belonging to this 
PDN connection. The number of EPS bearer Ids included is specified by the value of EPS Bearer ID Number. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 



Octets 

1 

2 to 3 

4 

5 

6 to (m+5) 
(m+6)- to 
(m+9) 
(m+10) 
(m+11)to 
(m+10+k) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 90 (decimal) 




Length = n 


Spare Instance 


HSGW Address for forwarding Length = m 


HSGW Address for forwarding [4..1 6] 


GRE Key 


EPS Bearer ID Number = k 


Spare 


EPS Bearer ID 



Figure 8.25-1: S103 PDN Data Forwarding Info 



8.26 S1 -U Data Forwarding (S1 UDF) 

The Serving GW Address and Serving GW Sl-U TEID consist the Sl-U Tunnel information allocated by the Serving 
GW for an EPS Bearer identified by the EPS Bearer ID which requires data forwarding during active handover from E- 
UTRAN Access to cdma2000 HRPD Access. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 



Octets 

1 

2 to 3 

4 

5 

6 

7 to (m+6) 

(m+7) to 

(m+10) 


Bits 
8 7 6 5 4 3 2 1 




Type = 91 (decimal) 




Length = n 


Spare 


Instance 


Spare 


EPS Bearer ID 


Serving GW Address Length = m 


Serving GW Address [4.. 16] 


Serving GW Sl-U TEID 



Figure 8.26-1: Sl-U Data Forwarding Info 



8.27 Delay Value 

Delay Value is coded as depicted in Figure 8.27-1. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 92 (decimal) 




Length = n 


Spare Instance 


Delay Value in integer multiples of 50 millisecs, or zero 


These octet(s) is/are present only if explicitly specified 



Figure 8.27-1 : Delay Value 

Delay Value is set to zero in order to clear a previously set delay condition. 
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8.28 Bearer Context 

Bearer Context is a grouped IE containing a number of other lEs. Which of those IBs are mandatory, optional or 
conditional and the conditions that apply are GTP message specific, and described in the corresponding subclause under 

clause 7. 

Bearer Context may be repeated within a message with exactly the same Type and Instance values to represent a list of 
Bearer Contexts. 

Bearer Context is coded as depicted in Table 8.28-1. 

Table 8.28-1 : Bearer Context Grouped Type 



Octet 1 


Bearer Context IE Type = 93 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information elements 


P Condition / Comment IE Type Ins. 


NOTE: This table uses a 5-column format in order to matcli the format used in subclauses of clause 7, where 
the usage of this IE is further detailed for each specific GTP message including it. 



8.29 Charging ID 



The Charging ID is coded as depicted in Figure 8.29-1. It is defined in 3GPP TS 32.251[8]. 



Octets 

1 
2 to 3 

4 

5-8 
9-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 94 (decimal) 




Length = 4 


Spare Instance 


Charging ID value 


These octet(s) is/are present only if explicitly specified 



Figure 8.29-1: Charging ID 



8.30 Charging Characteristics 



The charging characteristics information element is defined in 3GPP TS 32.251 [8] and is a way of informing both the 
SGW and PGW of the rules for producing charging information based on operator configured triggers. For the encoding 
of this information element see 3GPP TS 32.298 [9]. 



Octets 

1 
2 to 3 

4 

5 to 6 

7 to (n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 95 (decimal) 




Length = n 


Spare Instance 


Charging Characteristics value 


These octet(s) is/are present only if explicitly specified 



Figure 8.30-1: Charging Characteristics 



8.31 Trace Information 



Trace Information is coded as depicted in Figure 8.31-1. See 3GPP TS 32.422 [18] for details on trace related 
information. 
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Octets 

1 

2 to 3 

4 

5 

6 

7 

8to10 

11 to 19 

20 to 21 

22 

23 to 34 

35 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 96(decimal) 




Length = n 


Spare 


Instance 


MCC digit 2 


MCC digit 1 


MNCdigit3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Trace ID 


Triggering Events 




List of NE Types 


Session Trace Depth 


List of Interfaces 


IP Address of Trace Collection Entity 



Figure 8.31-1 : Trace Information 

Octets 5 to 10 represent the Trace Reference parameter as defined in 3GPP TS 32.422 [18], clause 5.6. 

Triggering Events, List of NE Types, Session Trace Depth and List of Interfaces are specified in 3GPP TS 32.422 [18] 

See 3GPP TS 24.008 [5], clause 10.5.1.4, Mobile Identity, for the coding of MCC and MNC, whose values are obtained 
from the serving PLMN that the EM/NM is managing. If MNC is 2 digits long, bits 5 to 8 of octet 6 are coded as 
"1111". 



8.32 Bearer Flags 

Bearer Flags is coded as depicted in Figure 8.32-1. 



Octets 

1 
2 to 3 

4 

5 
6-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 97 (decimal) 




Length = n 


Spare Instance 


Spare | VB | PPC 


These octet(s) is/are present only if explicitly specified 



Figure 8.32-1 : Bearer Flags 



The following bits within Octet 5 indicate: 



Bit 1 - PPC (Prohibit Payload Compression): This flag is used to determine whether an SGSN should attempt to 
compress the payload of user data when the users asks for it to be compressed (PPC = 0), or not (PPC =1). 

Bit 2 - VB (Voice Bearer): This flag is used to indicate a voice bearer when doing PS-to-CS SRVCC handover. 

8.33 Void 



8.34 PDN Type 

The PDN Type is coded as depicted in Figure 8.34-1. 



Octets 

1 

2 to 3 

4 

5 

6 to n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 99 (decimal) 




Length = n 


Spare Instance 


Spare | PDN Type 


These octet(s) is/are present only if explicitly specified 



Figure 8.34-1 : PDN Type 
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Table 8.34-1 : PDN Type 



PDN type value (octet 5) 

Bits 

3 2 1 

1 IPv4 

1 IPv6 

1 1 IPv4v6 

Bits 8-4 of octet 5 are spare and shall be coded as zero. 



8.35 Procedure Transaction ID (PTI) 



Procedure Transaction Id is coded as depicted in Figure 8.35-1. It is defined in 3GPP TS 24.301 [23], clause 9.4 and is 
coded as specified in 3GPP TS 24.007 [30], clause 1 1.2.3.1a Procedure transaction identity. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 100 (decimal) 




Length = n 


Spare Instance 


Procedure Transaction ID 


These octet(s) is/are present only if explicitly specified 



Figure 8.35-1 : Procedure Transaction ID 



8.36 DRX Parameter 

DRX Parameter indicates whether the UE use DRX mode or not, this parameter is coded as depicted in Figure 839-1. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 101 (decimal) 




Length = n 


Spare Instance 


DRX Parameter 



Figure 8.36-1 : DRX Parameter 



8.37 UE Network Capability 



UE Network Capability is coded as depicted in Figure 8.37-1. Actual coding of the UE Network Capability field is 
defined in 3GPP TS 24.301 [23]. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 102 (decimal) 




Length = n 


Spare Instance 


UE Network Capability 



Figure 8.37-1 : UE Network Capability 



8.38 MM Context 



The MM Context information element contains the Mobility Management, UE security parameters that are necessary to 
transfer over S3/S16/S10 interface. 
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All Spare bits are set to zeros by the sender and ignored by the receiver. Spare bits in MM Context IE shall be set to 1 's 
before sending MM Context IE to pre-R8 SGSN. 

Security Mode indicates the type of security keys (GSM/UMTS/EPS) and Authentication Vectors (quadruplets 
/quintuplets/triplets) that are passed to the new MME/SGSN. 

The DRX parameter coding is specified in clause 9.9.3.34 of 3GPP TS 24.008 [5]. If DRXI (DRX Indicator), bit 4 of 
octet 5, is set to "1", then the DRX parameter field is present, otherwise its octets are not present. 

Uplink/downlink Subscribed UE AMBR (Aggregate Maximum Bit Rate) is coded as Unsigned32 integer values in kbps 
(1000 bps) for all non-GBR bearers according to the subscription of the user. If SAMBRI (Subscribed UE AMBR 
Indicator), bit 1 of octet 6, is set to "1", then the Uplink/downlink Subscribed UE AMBR parameter field is present, 
otherwise these parameters are not present. 

Uplink/downlink Used UE AMBR (Aggregate Maximum Bit Rate) is coded as Unsigned32 integer values in kbps 
(1000 bps) for all non-GBR bearers currently being used by the UE. If UAMBRI (Used UE AMBR Indicator), bit 2 of 
octet 6, is set to "1", then the Uplink/downlink Used UE AMBR parameter field is present, otherwise these parameters 
are not present. 

The encoding of Mobile Equipment Identity (MEI) field shall be same as specified in clause 8.10 of this specification. If 
Length of Mobile Equipment Identity is zero, then the Mobile Equipment Identity parameter shall not be present. 

The UE Network Capability coding is specified in clause 9.9.3.34 of 3GPP TS 24.301 [23]. If Length of UE Network 
Capability is zero, then the UE Network Capability parameter shall not be present. 

The MS Network CapabiHty coding is specified in clause 10.5.5. 12 of 3GPP TS 24.008 [5]. If Length of MS Network 
Caapability is zero, then the MS Network Capability parameter shall not be present. 

Used Cipher indicates the GSM ciphering algorithm that is in use. 

Used NAS Cipher indicates the EPS ciphering algorithm that is in use. 

The Access restriction data is composed of UNA(UTRAN Not Allowed), GENA(GERAN Not Allowed), GANA(GAN 
Not Allowed), INA(I-HSPA-Evolution Not Allowed), ENA(E-UTRAN Not Allowed) and HNNA(HO-To-Non-3GPP- 
Access Not Allowed). 

As depicted in Figure 8.38-1, the GSM Key, Used Cipher and Authentication Triplets that are unused in the old SGSN 
shall be transmitted to the new SGSN for the GSM subscribers. 

The Authentication Triplet coding is specified in Figure 8.38-7. 



Octets 

1 
2 to 3 
4 
5 
6 

7 
8 to 15 
16toh 
(h+1)to 

(h+2) 

J to (j+3) 

(j+4) to (j+7) 

i to (i+3) 
(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 

(m+2) to r 

r+1 

(r+2) to 


Bits 
8 7 6 5 4 3 2 1 




Type = 103 (decimal) 




Length = n 


Spare 


Instance 


Security IVIode 


Spare 


DRXI 1 CKSN 


Number of Triplet 


Spare 


UAMB 
Rl 


SAMB 
Rl 


Spare Used Cipher 


Kc 


Authentication Triplet [0..4] 


DRX parameter 


Uplink Subscribed UE AMBR 


Downlink Subscribed UE AIVIBR 


Uplink Used UE AMBR 


Downlink Used UE AMBR 


Length of UE Network Capability 


UE Network Capability 


Length of MS Network Capability 


MS Network Capability 


Length of Mobile Equipment Identity (MEI) 


Mobile Equipment Identity (MEI) 


Spare HNNA 


ENA 


INA GANA 


GENA 


UNA 


These octet(s) is/are present only if explicitly specified 
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(n+4) 



Figure 8.38-1 : GSM Key and Triplets 

As depicted in Figure 8.38-2, the UMTS Key, Used Cipher and Authentication Quintuplets that are unused in the old 
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in 
case the user has a ME capable of UMTS AKA. 

The Authentication Quintuplet coding is specified in Figure 8.38-8. 



Octets 

1 
2 to 3 
4 
5 
6 

7 
8 to 23 
24 to 39 
40toh 
(h+1)to 

(h+2) 
J to (j+3) 

(j+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 

(m+2) to r 

r+1 

(r+2) to 

(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 104 (decimal) 




Length = n 


Spare 


Instance 


Security IVIode 


Spare 


DRX! 1 CKSN/KSI 


Number of 
Quintuplets 


Spare 


UAMB SAMB 
Rl Rl 


Spare Used Cipher 


CK 


IK 


Authentication Quintuplet [0..4] 


DRX parameter 


Uplink Subscribed UE AIVIBR 


Downlink Subscribed UE AMBR 


Uplink Used UE AMBR 


Downlink Used UE AMBR 


Length of UE Network Capability 


UE Network Capability 


Length of MS Network Capability 


MS Network Capability 


Length of Mobile Equipment Identity (ME!) 


Mobile Equipment Identity (ME!) 


Spare |HNNA| ENA | INA |GANA|GENA| UNA 


These octet(s) is/are present only if explicitly specified 



Figure 8.38-2: UMTS Key, Used Cipher and Quintuplets 

As depicted in Figure 8.38-3, the GSM Key, Used Cipher and Authentication Quintuplets that are unused in the old 
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in 
case the user has a ME no capable of UMTS AKA. 

The Authentication Quintuplet coding is specified in Figure 8.38-8. 
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Octets 

1 
2 to 3 
4 
5 
6 

7 
8 to 15 
16toh 
(li+1)to 

(h+2) 

j to (j+3) 

(j+4) to (j+7) 

i to (i+3) 
(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 

(m+2) to r 

r+1 

(r+2) to 

(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 105 (decimal) 




Length = n 


Spare 


Instance 


Security IVIode 


Spare 


DRXI 1 CKSN/KSI 


Number of 
Quintuplets 


Spare 


UAMB SAMB 
Rl Rl 


Spare Used Cipher 


Kc 


Authentication Quintuplets [0..4] 


DRX parameter 


Uplink Subscribed UEAMBR 


Downlink Subscribed UE AIVIBR 


Uplink Used UE AMBR 


Downlink Used UE AMBR 


Length of UE Network Capability 


UE Network Capability 


Length of IVIS Network Capability 


IVIS Network Capability 


Length of IVIobile Equipment Identity (ME!) 


Mobile Equipment Identity (MEI) 


Spare |HNNA| ENA | INA |GANA|GENA| UNA 


These octet(s) is/are present only if explicitly specified 



Figure 8.38-3: GSM Key, Used Cipher and Quintuplets 

As depicted in Figure 8.38-4, the UMTS Key, KSI and unused Authentication Quintuplets in the old SGSN may be 
transmitted to the new SGSN/MME when the UMTS subscriber is attached to UTRAN/GERAN in the old system, but 
it is not allowed to send quintuplets to an MME in a different serving network domain (see 3GPP TS 33.401 [12] clause 
6.1.6). The MME may forward the UMTS Key, KSI and unused Authentication Quintuplets which were previously 
stored back to the same SGSN, for further details, refer to 3GPP TS 33.401 [12]. 

The Authentication Quintuplet coding is specified in Figure 8.38-8. 



Octets 

1 
2 to 3 
4 
5 
6 

7 
8 to 23 
24 to 39 
40toh 
(h+1)to 

(h+2) 
j to (j+3) 

(j+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 

(m+2) to r 

r+1 

(r+2) to 

(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 106 (decimal) 




Length = n 


Spare 


Instance 


Security Mode 


Spare 


DRXI 1 KSI 


Number of 
Quintuplets 


Spare 


UAMB 
Rl 


SAMB 
Rl 


Spare 


CK 


IK 


Authentication Quintuplet [0..4] 


DRX parameter 


Uplink Subscribed UE AMBR 


Downlink Subscribed UE AMBR 


Uplink Used UE AMBR 


Downlink Used UE AMBR 


Length of UE Network Capability 


UE Network Capability 


Length of MS Network Capability 


MS Network Capability 


Length of Mobile Equipment Identity (MEI) 


Mobile Equipment Identity (MEI) 


Spare |HNNA| ENA | INA |GANA|GENA| UNA 


These octet(s) is/are present only if explicitly specified 



Figure 8.38-4: UMTS Key and Quintuplets 



£75/ 



3GPP TS 29.274 version 8.10.0 Release 8 



123 



ETSI TS 129 274 V8.10.0 (2011-06) 



As depicted in Figure 8.38-5, the current EPS Security Context, a non-current EPS Security Context (if available), and 
unused Authentication Quadruplets in the old MME may be transmitted to the new MME. If the new MME is not in the 
same serving network domain then only the current EPS Security Context may be transmitted.Authentication 
Quintuplets shall not be transmitted to the new MME even if the old MME has the Authentication Quintuplets for this 
UE. The value in Number of Quintuplets field shall be set to '0'. The reasons for not sending Quintuplets are specified 
in3GPPTS 33.401 [12] clause 6.1.6. 

The Authentication Quintuplet and Authentication Quadruplet codings are specified in Figure 8.38-8 and Figure 8.38-9 
respectively. 

The value of the NAS Downlink Count shall be set to the value that shall be used to send the next NAS message. 

The value of the NAS Uplink Count shall be set to the largest NAS Uplink Count that was in a successfully integrity 
protected NAS message. 

In Figure 8.38-5, the fields for the Old EPS Security Context (i.e. octets from s to sH-64) may be present only in SIO 
Forward Relocation Request message according to the Rules on Concurrent Running of Security Procedures, which are 
specified in 3GPP TS 33.401 [12]. The octets for Old EPS Security Context shall be present if the OSCI (Old Security 
Context Indicator), bit 1 of octet 6) is set to "1"; otherwise they shall not be present. 

If NHI_old (Next Hop Indicator for old EPS Security Context), bit I of octet s, is set to "1", then the parameters old NH 
(Next Hop) and old NCC (Next Hop Chaining Count) shall be present; otherwise the octets for old NH parameter shall 
not be present and the value of old NCC parameter shall be ignored by the receiver. 



Octets 

1 
2 to 3 
4 
5 
6 

7 

8 to 10 
11 to 13 
14 to 45 
46 tog 
(g+1)toh 
(h+1)to 
(h+2) 

pto (p+31) 

p+32 

j to (1+3) 

(1+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 
(m+2) to r 

r+1 
s 

(s+1)to 
(s+32) 

(s+33) to 
(s+64) 

t to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 107 (decimal) 




Length = n 


Spare 


Instance 


Security IVIode 


NH! 


DRXI 1 KSIasme 


Number of 
Quintuplets 


Number of 
Quadruplet 


UAMB 
Rl 


OSCI 


SAME 
Rl 


Used NAS integrity 
protection algorithm 


Used NAS Cipher 


NAS Downlink Count 


NAS Uplink Count 


Kasme 


Authentication Quadruplet [0..4] 


Authentication Quintuplet [0..4] 


DRX parameter 


NH 


Spare | NCC 


Uplink Subscribed UE AIVIBR 


Downlink Subscribed UE AMBR 


Uplink Used UE AMBR 


Downlink Used UE AMBR 


Length of UE Network Capability 


UE Network Capability 


Length of MS Network Capability 


MS Network Capability 


Length of Mobile Equipment Identity (ME!) 


Mobile Equipment Identity (ME!) 


Spare 


HNNAl ENA | INA 


GANA|GENA| UNA 


NH! 
Id 


Spare 


old KSIasme 


old NCC 


old Kasme 


oldNH 


These octet(s) is/are present only if explicitly specified 



Figure 8.38-5: EPS Security Context and Quadruplets 

If NHI (Next Hop Indicator), bit 5 of octet 5, is set to "1", then the optional parameters NH (Next Hop) and NCC (Next 
Hop Chaining Count) are both present, otherwise their octets are not present. 
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As depicted in Figure 8.38-6, the old MME will derive CK' and IK' from Kasme and transmit the CK' and IK' to the new 
SGSN. Authentication Quintuplets, if available, shall be transmitted to the SGSN if, and only if the MME received 
them from this SGSN earlier, according to 3GPP TS 33.401 [12] clause 6.1.5. 

The value in Number of Quadruplets field shall be set to '0', if Authentication Quadruplets are not present. A key Kasme 
shall never be transmitted to an SGSN according to 3GPP TS 33.401 [12] clause 6.4. 

The Authentication Quintuplet and Authentication Quadruplet codings are specified in Figure 8.38-8 and Figure 8.38-9 
respectively. 

The old SGSN/MME may deliver both Authentication Quadruplets and Authentication Quintuplets it holds to the peer 
combo node to optimize the procedure. 



Octets 

1 
2 to 3 
4 
5 
6 

7 
8 to 23 
24 to 39 
40 tog 
(g+1)toh 
(h+1)to 

(h+2) 
J to (1+3) 

(1+4) to (j+7) 
i to (i+3) 

(i+4) to (i+7) 

q 

(q+1)tok 

k+1 
(k+2) to m 

m+1 

(m+2) to r 

r+1 

(r+2) to 

(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 108 (decimal) 




Length = n 


Spare 


Instance 


Security IVIode 


Spare 


DRX! 1 KSJASME 


Number of 
Quintuplets 


Number of 
Quadruplet 


UAMB SAMB 
Rl Rl 


Spare 


CK 


IK 


Authentication Quadruplet [0..4] 


Authentication Quintuplet [0..4] 


DRX parameter 


Uplink Subscribed UE AMBR 


Downlink Subscribed UE AIVIBR 


Uplink Used UE AMBR 


Downlink Used UE AMBR 


Length of UE Network Capability 


UE Network Capability 


Length of MS Network Capability 


MS Network Capability 


Length of Mobile Equipment Identity (ME!) 


Mobile Equipment Identity (ME!) 


Spare |HNNA| ENA | INA |GANA|GENA| UNA 


These octet(s) is/are present only if explicitly specified 



Figure 8.38-6: UMTS Key, Quadruplets and Quintuplets 



Octets 

1 to 16 
17 to 20 
21 to 28 


8 


7 


6 


Bits 
5 4 


3 


2 


1 




RAND 




SRES 


Kc 



Figure 8.38-7: Authentication Triplet 



Octets 

1 to 16 

17 

18tom 

(m+1) to 

(m+1 6) 

(m+1 7) to 

(m+32) 

m+33 

(m+34) to n 


Bits 
8 7 6 5 4 3 


2 1 




RAND 




XRES Length 


XRES 


CK 


IK 


AUTN Length 


AUTN 



Figure 8.38-8: Authentication Quintuplet 
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Octets 

1 to 16 

17 

18tok 

k+1 

(k+2) to m 

(m+1)to 

(m+32) 


Bits 
8 7 6 5 4 3 


2 1 




RAND 




XRES Length 


XRES 


AUTN Length 


AUTN 


Kasme 



Figure 8.38-9: Authentication Quadruplet 
Table 8.38-1 : Security Mode Values 



Security Type 


Value (Decimal) 


GSM Key and Triplets 





UMTS Key, Used Cipher and Quintuplets 


1 


GSM Key, Used Cipher and Quintuplets 


2 


UMTS Key and Quintuplets 


3 


EPS Security Context and Quadruplets 


4 


UMTS Key, Quadruplets and Quintuplets 


5 




Table 8.38-2: Used NAS Cipher Values 






Cipher Algorithm 


Value (Decimal) 






No ciphering 









128-EEA1 


1 






128-EEA2 


2 






EEA3 


3 






EEA4 


4 






EEA5 


5 






EEA6 


6 






EEA7 


7 






Table 8.38-3: Used Cipher Values 






Cipher Algorithm 


Value (Decimal) 






No ciphering 









GEA/1 


1 






GEA/2 


2 






GEA/3 


3 






GEA/4 


4 






GEA/5 


5 






GEA/6 


6 






GEA/7 


7 




Table 


8.38-4: Used NAS integrity protection algorithm V 


'alues 




Integrity protection 
Algorithm 


Value (Decimal) 






Spare 









128-EIA1 


1 






128-EIA2 


2 






El A3 


3 






EIA4 


4 






EIA5 


5 






EIA6 


6 






EIA7 


7 
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8.39 PDN Connection 

The PDN connection is a grouped IE containing a number of other lEs and shall be coded as depicted in Table 8.39-1. 

The PDN Connection IE may be repeated within a message when more than one PDN Connection is required to be sent. 
If so, the repeated lEs shall have exactly the same Instance values to represent a list of grouped lEs. 

Table 8.39-1 : PDN Connection Grouped Type 



Octet 1 


PDN Connection IE Type = 109 (decimal) 


Octets 2 and 3 


Length = n 


Octet 4 


Spare and Instance fields 


Information 
elements 


P 


Condition / Comment 


IE Type 


Ins. 


NOTE: This table uses a 5-column format in order to matcli the format used in subclauses of clause 7, where 
the usage of this IE is further detailed for each specific GTP message including it. 



8.40 PDU Numbers 

The PDU Numbers information element contains the sequence number status corresponding to a Bearer context in the 
old SGSN. This information element shall be sent only when acknowledged peer-to-peer LLC operation is used for the 
Bearer context or when the "delivery order" QoS attribute is set in the Bearer context QoS profile. 

NSAPI identifies the Bearer context for which the PDU Number IE is intended. 

DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE when "delivery 
order" is set. 

UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the S-GW when 
"delivery order" is set. 

The Send N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer context. 
Send N-PDU Number is the N-PDU number to be assigned by SNDCP to the next down link N-PDU received from the 
S-GW. 

The Receive N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer 
context. The Receive N-PDU Number is the N-PDU number expected by SNDCP from the next up link N-PDU to be 
received from the UE. 

The PDU Number IE will be repeated for each Bearer Context for which this IE is required. 

PDU Numbers IE is coded as depicted in Figure 8.40-1. 



Octets 

1 

2 to 3 

4 

5 

6-7 

8-9 

10-11 

12-13 

14 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 110 (decimal) 




Length = n 


Spare 


Instance 


Spare(0 0) 


NSAPI 


DL GTP-U Sequence Number 


UL GTP-U Sequence Number 


Send N-PDU Number 


Receive N-PDU Number 


These octet(s) is/are present only if explicitly specified 



Figure 8.40-1: PDU Numbers 



8.41 Packet TMSI(P-TMSI) 

The P-TMSI, unambiguously associated with a given UE and routeing area, is given by: 
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Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 111 (decimal) 




Length = n 


Spare Instance 


Packet TMSI (P-TMSI) 
The P-TMSI is defined in 3GPP TS 23.003 [2]. 



Figure 8.41-1 : Packet TMSI (P-TMSI) 



8.42 P-TMSI Signature 



The content and the coding of the P-TMSI Signature information element are defined in 3GPP TS 24.008 [5]. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 112 (decimal) 




Length = n 


Spare Instance 


P-TIVISI Signature 



Figure 8.42-1 : P-TMSI Signature 



8.43 Hop Counter 



Where Intra Domain Connection of RAN Nodes to Multiple CN Node is applied, the Hop Counter may be used to 
prevent endless loops when relaying Identification Request messages and Context Request messages. The maximum 
value is operator specific and shall not be lower than 1 . 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 113 (decimal) 




Length = n 


Spare Instance 


Hop Counter 


These octet(s) is/are present only if explicitly specified 



Figure 8.43-1 : Hop Counter 



8.44 UE Time Zone 

UE Time Zone is used to indicate the offset between universal time and local time in steps of 15 minutes of where the 
UE currently resides. The "Time Zone" field uses the same format as the "Time Zone" IE in 3GPP TS 24.008 [5]. 

UE Time Zone is coded as this is depicted in Figure 8.44-1. The value of the Time Zone field represents the time zone 
adjusted for daylight saving time. The value of the Daylight Saving Time field specifies the adjustment that has been 
made. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 



Octets 

1 
2 to 3 
4 
5 
6 

7 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type =114 (decimal) 




Length = n 


Spare Instance 


Time Zone 


Spare 


Daylight 
Saving Time 


These octet(s) is/are present only if explicitly specified 



Figure 8.44-1 : UE Time Zone 
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Table 8.44-2 Possible values for the "Daylight Saving Time" field and their meanings. 



Daylight Saving Time 


Value (binary) 


Bit 2 


Biti 


No adjustment for Daylight Saving Time 








+1 hour adjustment for Daylight Saving Time 





1 


+2 hours adjustment for Daylight Saving Time 


1 





Spare 


1 


1 



8.45 Trace Reference 



Trace Reference shall be coded as depicted in Figure 8.45-1. See 3GPP TS 32.422 [18], clause 5.6, for the definition of 
Trace Reference. 

See 3GPP TS 24.008 [5], clause 10.5.1.4, Mobile Identity, for the coding of MCC and MNC, whose values are obtained 
from the serving PLMN that the EM/NM is managing. If MNC is 2 digits long, bits 5 to 8 of octet 6 are coded as 
"1111". 



Octets 

1 
2 to 3 

4 

5 

6 

7 
BtolO 


Bits 
8 7 6 5 4 3 2 1 




Type =115 (decimal) 




Length = 6 


Spare 


Instance 


MCC digit 2 


MCC digit 1 


MNC digit 3 


MCC digit 3 


MNC digit 2 


MNC digit 1 


Trace ID 



Figure 8.45-1 : Trace Reference 



8.46 Complete Request Message 

The Complete Request Message is coded as depicted in Figure 8.46-1. 



Octets 

1 

2 to 3 

4 

5 

6- to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 116 (decimal) 




Length = n 


Spare Instance 


Complete Request Message Type 


Complete Request Message 



Figure 8.46-1 : Complete Request Message 

Complete Request Message type values are specified in Table 8.46-1. 

Table 8.46-1 : Complete Request Message type values and their meanings 



Location Types 


Values (Decimal) 


Complete Attach Request Message 





Complete TAU Request Message 


1 


<spare> 


2-255 



8.47 GUTI 

The GUTI is coded as depicted in Figure 8.47-1. 
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Octets 

1 

2 to 3 

4 

5 

6 

7 

8 to 9 

10 

1 1 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type =117 (decimal) 




Length = n 


Spare 


Instance 


MCCdigit2 


MCC digit 1 


MNCdigitS 


MCC digit 3 


MNCdigit2 


MNC digit 1 


MME Group ID 


MME Code 


M-TMSI 



Figure 8.47-1 :GUTI 

If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111". 

8.48 Fully Qualified Container (F-Container) 

Fully Qualified Container (F-TEID) is coded as depicted in Figure 8.48-1. 

All Spare bits are set to zeros by the sender and ignored by the receiver. If the F-Container field is constructed from the 
received container in the message on the lu-PS or Sl-AP interface, the F-Container field shall be encoded as the content 
part (excluding IE-ID, criticality, pad and length part) of corresponding parameter. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 118 (decimal) 




Length = n 


Spare 


Instance 


Spare 


Container Type 


F-Container field 



Figure 8.48-1 : Full Qualified Container (F-Container) 

The Container Type is coded as below: 

If this field is set to 1, then the F-Container field present the UTRAN transparent container, which contains 
ASN. 1/PER encoded binary value of a transparent container parameter (e.g. "Target RNC to Source RNC 
Transparent Container") as specified in 3GPP TS 25.413 [33]. 

If this field is set to 2, then the F-Container field present the BSS container. 

If this field is set to 3, then the F-Container field present the E-UTRAN transparent container, which contains 
ASN. 1/PER encoded binary value of a transparent container parameter (e.g. "Target eNB to Source eNB 
Transparent Container" as specified in 3GPP TS 36.413 [10]. 

The BSS Container IE in the Bearer Context IE in Forward Relocation Request and Context Response messages is 
coded as depicted in Figure 8.48-2. 



Octets 

6 
a 
b 
c 
d to n 


Bits 
8 7 6 5 4 3 2 1 




Spare | PHX | SARI | RP | PFI 




Packet Flow ID 


SAPI 1 Spare | Radio Priority 


XID parameters length 


XiD parameters 



Figure 8.48-2: BSS Container 

The flags PFI, RP, SAPI and PHX in octet 6 indicate the corresponding type of parameter (Packet FlowID, Radio 
Priority, SAPI and PS handover XID parameters) shall be present in a respective field or not. If one of these flags is set 
to "0", the corresponding field shall not be present at all. The Spare bit shall be set to zero by the sender and ignored by 
the receiver. 

If PFI flag is set. Packet Flow ID shall be present in Octet a. 
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If RP flag is set, Radio Priority shall be present in Octet b. 
If SAPl flag is set, S API shall be present in Octet b. 
If PHX flag is set: 

XiD parameters length is present in Octet c. 

XiD parameters are present in Octet d to n. 

8.49 Fully Qualified Cause (F-Cause) 

Fully Qualified Cause (F- Cause) is coded as depicted in Figure 8.49-1. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 119 (decimal) 




Length = n 


Spare 


Instance 


Spare 


Cause Type 


F-Cause field 



Figure 8.49-1 : Full Qualified Cause (F-Cause) 

The value of Instance field of the F-Cause IE in a GTPv2 message shall indicate whether the F-Cause field contains 
RANAP Cause, BSSGP Cause or RAN Cause. If the F-Cause field contains RAN Cause, the Cause Type field shall 
contain the RAN cause subcategory as specified in 3GPP TS 36.413 [10] and it shall be encoded as in Table 8.49-1. If 
the F-Cause field contains BSSGP Cause or RANAP Cause, the Cause Type field shall be ignored by the receiver. 

All spare bits shall be set to zeros by the sender and ignored by the receiver. 

F-Cause field is coded as follows: 

For RANAP Cause, the F-Cause field contains the cause as defined in 3GPP TS 25.413 [33]. The value of F- 
Cause field (which has a range of 1.. 5 12) is transferred over the lu interface and encoded into two octet as binary 
integer. 

- For BSSGP Cause, the F-Cause field contains the cause as defined in 3GPP TS 48.018 [34]. The value of F- 
Cause field (which has a range of 1..255) is transferred over the Gb interface and encoded into one octet as 
binary integer. 

For RAN Cause, the F-Cause field contains the cause as defined in clause 9.2.1.3 in 3GPP TS 36.413 [10]. The 
value of F-Cause field (and the associated RAN cause subcategory) is transferred over the Sl-AP interface and 
encoded into one octet as binary integer. 

Table 8.49-1 : Cause Type values and their meanings 



Cause Type 


Values (Decimal) 


Radio Network Layer 





Transport Layer 


1 


NAS 


2 


Protocol 


3 


IVIiscellaneous 


4 


<spare> 


5to15 



8.50 Selected PLIVIN ID 

The Selected PLMN ID IE contains the core network operator selected for tne UE in a shared network. Octets 5-7 shall 
be encoded as the content part of the "Selected PLMN Identity" parameter in 3GPP TS 36.413 [10]. 
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Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 120 (decimal) 




Length = n 


Spare Instance 


Selected PLMN ID 



Figure 8.50-1 : Selected PLMN ID 



8.51 Target Identification 



The Target Identification information element is coded as depicted in Figure 8.51-1. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 121 (decimal) 




Length = n 


Spare Instance 


Target Type 


Target ID 



Figure 8.51-1 : Target Identification 

Target Type values are specified in Table 8.51-1. 

The Target Type is RNC ID for SRNS relocation procedure and handover to UTRAN. In this case the "Target ID" field 
shall be encoded as specified in Figure 8.51-la below. The ASN.l/PER encoding of the "Target RNC -ID" part of the 
"Target ID" parameter is specified in 3GPP TS 25.413 [33]. The preamble of the "Target RNC-ID" (numerical value of 
e.g. 0x20) shall not be included into octets 6 to (n+4). Also, the optional "iE-Extensions" parameter shall not be 
included into the GTP IE. 



Octets 

6 

7 

8 

9 to 10 

11 

12to13 

a to (a+1) 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 2 


IVICC digit 1 




MNC digit 3 


MCC digit 3 


MNCdigit2 


MNC digit 1 


LAC 


RAG (see NOTE) 


RNC-ID 


Extended RNC-ID (optional) 



Figure 8.51-1a: Target ID for Type RNC ID 

If only two digits are included in the MNC, then bits 5 to 8 of octet 7 (MNC digit 3) shall be coded as " 11 U". 

The location area code (LAC) consists of 2 octets. Bit 8 of octet 9 is the most significant bit and bit 1 of octet 10 is the 
least significant bit. The coding of the location area code is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

The RNC-ID consists of 2 octets and contains 12 bits long value (see 3GPP TS 25.413 [7]). Bit 4 of octet 12 is the most 
significant bit and bit 1 of octet 13 is the least significant bit (bits 8 to 5 of octet 12 are set to 0). The coding of the 
RNC-ID is the responsibility of each administration. Coding using full hexadecimal representation shall be used. 

If the optional Extended RNC-ID is not included, then the length variable 'n' = 8 and the overall length of the IE is 13 
octets. Otherwise, 'n' = 10 and the overall length of the IE is 15 octets. 

NOTE: In the "TargetRNC-ID" ASN. 1 type definition in 3GPP TS 25.413 [7] the "RAC" parameter is marked as 
optional. RAC is however always available at an SGSN/MME when it sends the RAC in a GTPv2 
Forward Relocation Request message. 

If the optional Extended RNC-ID is included, then the receiver shall ignore the RNC-ID (see 3GPP TS 25.413 [7]). 

The Target Type is eNodeB ID for handover to E-UTRAN. In this case the coding of the Target ID field shall be coded 
as depicted in Figure 8.51-2. 
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Octets 

6 

7 

8 

9 
10 to 11 
12to13 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 2 


IVICC digit 1 




MNC digit 3 


IVICC digit 3 


l\/INCdigit2 


IVINC digit 1 


Spare 


IVIacro eNodeB ID 


IVIacro eNodeB ID 


Tracl<ing Area Code (TAG) 



Figure 8.51-2: Target ID for Type eNodeB 

The Macro eNodeB ID consists of 20 bits. Bit 4 of Octet 4 is the most significant bit and bit 1 of Octet 6 is the least 
significant bit. The coding of the Macro eNodeB ID is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

The Target Type is Cell Identifier for handover to GERAN. In this case the coding of the Target ID field shall be same 
as the Octets 3 to 10 of the Cell Identifier lEI in 3GPP TS 48.018 [34]. 

Table 8.51-1 : Target Type values and their meanings 



Target Types 


Values (Decimal) 


RNCID 





eNodeB ID 


1 


Cell Identifier 


2 


<spare> 


3 to 255 



8.52 Void 



8.53 Packet Flow ID 

The Packet Flow Id information element contains the packet flow identifier assigned to a PDP context as identified by 
EPS Bearer ID. 

The spare bits 8 to 5 in octet 5 indicate unused bits, which shall be set to by the sending side and which shall not be 
evaluated by the receiving side. 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 123 (decimal) 




Length = n 


Spare 


Instance 


Spare 


EBI 


Packet Flow ID 



Figure 8.53-1 : Packet Flow ID 



8.54 RAB Context 



The RAB Context shall be coded as is depicted in Figure 8.54-1. 



£75/ 



3GPP TS 29.274 version 8.10.0 Release 8 



133 



ETSI TS 129 274 V8.10.0 (2011-06) 



Octets 

1 

2 to 3 

4 

5 

6 to 7 

8 to 9 

10 to 11 

12to13 


Bits 
8 7 6 5 4 3 2 


1 




Type = 124 (decimal) 




Length = 9 


Spare 


Instance 


Spare 


NSAPI 


DL GTP-U Sequence Number 


UL GTP-U Sequence Number 


DL PDCP Sequence Number 


UL PDCP Sequence Number 



Figure 8.54-1 : RAB Context 

The RAB Context IE may be repeated within a message with exactly the same Type and Instance to represent a list. 

The RAB context information element contains sequence number status for one RAB in RNC, which corresponds to 
one PDP context. The RAB contexts are transferred between the RNCs via the SGSNs at inter SGSN hard handover. 

NSAPI identifies the PDP context and the associated RAB for which the RAB context IE is intended. 

DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE. 

UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the SGW. 

DL PDCP Sequence Number is the number for the next downlink PDCP-PDU to be sent to the UE. 

UL PDCP Sequence Number is the number for the next uplink PDCP-PDU to be received from the UE. 



8.55 Source RNC PDCP context info 

The purpose of the Source RNC PDCP context info IE is to transfer RNC PDCP context information from a source 
RNC to a target RNC during an SRNS relocation. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 125 (decimal) 




Length = n 


Spare Instance 


RRG Container 



Figure 8.55-1 : Source RNC PDCP context info 



8.56 UDP Source Port Number 

UDP Source Port Number is coded as depicted in Figure 8.56-1. 



Octets 

1 
2 to 3 

4 

5 to 6 

7 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 126 (decimal) 




Length = 2 


Spare Instance 


UDP Source Port Number 


These octet(s) is/are present only if explicitly specified 



Figure 8.56-1 : UDP Source Port Number 



8.57 APN Restriction 



The APN Restriction information element contains an unsigned integer value indicating the level of restriction imposed 
on EPS Bearer Contexts created to the associated APN. 
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The APN Restriction IE is coded as depicted in Figure 8.57-1: 



Octets 

1 

2 to 3 

4 

5 

6 to (n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 127 (decimal) 




Length = n 


Spare Instance 


Restriction Type value 


These octet(s) is/are present only if explicitly specified 



Figure 8.57-1 : APN Restriction Type Information Element 

An APN Restriction value may be configured for each APN in the PGW. It is used to determine, on a per UE basis, 
whether it is allowed to establish EPS bearers to other APNs. 

Table 8.57-1 : Valid Combinations of APN Restriction 



Maximum 

APN 
Restriction 

Value 


Type of APN 


Application Example 


APN Restriction Value allowed to be 
established 





No Existing Contexts or Restriction 


All 


1 


Public-1 


MMS 


1,2,3 


2 


Public-2 


Internet 


1,2 


3 


Private-1 


Corporate (e.g. who use 
MMS) 


1 


4 


Private-2 


Corporate (e.g. who do not 
use MMS) 


None 



8.58 Selection Mode 

The Selection mode information element indicates the origin of the APN in the message. 



Octets 

1 

2 to 3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 128 (decimal) 




Length = n 


Spare Instance 


Spare 


Selec. Mode 



Figure 8.58-1 : Selection Mode Information Element 
Table 8.58-1 : Selection Mode Values 



Selection mode value 


Value (Decimal) 


MS or network provided APN, subscribed verified 





MS provided APN, subscription not verified 


1 


Network provided APN, subscription not verified 


2 


For future use. Shall not be sent. If received, shall be interpreted as the value "2". 


3 



8.59 Source Identification 

The Source Identification information element is coded as depicted in Figure 8.59-1. 
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Octets 

1 
2 to 3 

4 

5 to 12 

13 

14 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 129 (decimal) 




Length = n 


Spare Instance 


Target Cell ID 


Source Type 


Source ID 



Figure 8.59-1 : Source Identification 

The Target Cell ID shall be same as the Octets 3 to 10 of the Cell Identifier lEI in 3GPP TS 48.018 [34]. 

Source Type values are specified in Table 8.59-1. 

The Source Type is Cell ID for PS handover from GERAN A/Gb mode. In this case the coding of the Source ID field 
shall be same as the Octets 3 to 10 of the Cell Identifier lEI in 3GPP TS 48.018 [34]. 

The Source Type is RNC ID for PS handover from GERAN lu mode or for inter-RAT handover from UTRAN. In this 
case the Source ID field shall be encoded as the Source RNC -ID part of the "Source ID" parameter in 3GPP TS 25.413 
[33]. Therefore, ASN.l/PER encoded binary value of the "Source RNC ID" shall be copied into octets 14 to (nH-4). 

Table 8.59-1 : Source Type values and their meanings 



Source Types 


Values (Decimal) 


Cell ID 





RNC ID 


1 


reserved (NOTE) 


2 


<spare> 


3-255 


NOTE: This value was allocated in an earlier version of the protocol and 
shall not be used. 



8.60 Void 



8.61 Change Reporting Action 

Change Reporting Action IE is coded as depicted in Figure 8.61-1. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 131 (decimal) 




Length = n 


Spare Instance 


Action 



Figure 8.61-1 : Change Reporting Action 
Table 8.61-1 : Action values 



Action 


Value (Decimal) 


Stop Reporting 





Start Reporting CGI/SAI 


1 


Start Reporting RAI 


2 


Start Reporting TAI 


3 


Start Reporting ECGI 


4 


Start Reporting CGI/SAI and RAI 


5 


Start Reporting TAI and ECGI 


6 


<spare> 


7-255 



Stop Reporting stops all reporting action types. 
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8.62 Fully qualified PDN Connection Set Identifier (FQ-CSID) 

A fully qualified PDN Connection Set Identifier (FQ-CSID) identifies a set of PDN connections belonging to an 
arbitrary number of UEs on a MME, SOW or PGW. The FQ-CSID is used on S5, S8 and S 11 interfaces. 

The size of CSID is two octets. The FQ-CSID is coded as follows: 



Octets 

1 

2 to -3 

4 

5 

6 top 

(p+1)to 

(P+2) 

(p+3) to 

(p+4) 

q to q+1 

(q+2) to 

(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 132 (decimal) 




Length = n 


Spare 


Instance 


Node- ID Type 


Number of CSIDs= m 


Node-ID 


First PDN Connection Set Identifier (CSID) 


Second PDN Connection Set Identifier (CSID) 




m-th PDN Connection Set Identifier (CSID) 


These octet(s) is/are present only if explicitly specified 



Figure 8.62-1 : FQ-CSID 

Where Node-ID Type values are: 

indicates that Node-ID is a global unicast IPv4 address and p = 9. 

1 indicates that Node -ID is a global unicast IPv6 address and p = 21. 

2 indicates that Node-ID is a 4 octets long field with a 32 bit value stored in network order, and p= 9. The coding 
of the field is specified below: 

- Most significant 20 bits are the binary encoded value of (MCC * 1000 + MNC). 

Least significant 12 bits is a 12 bit integer assigned by an operator to an MME, SGW or PGW. Other values of 
Node-ID Type are reserved. 

Values of Number of CSID other than 1 are only employed in the Delete PDN Connection Set Request and Response. 

The node that creates the FQ-CSID, (i.e. MME for MME FQ-CSID, SGW for SGW FQ-CSID, and PGW for PGW 
FQ-CSID), is responsible for making sure the Node-ID is globally unique and the CSID value is unique within that 
node. 

When a FQ-CSID is stored by a receiving node, it is stored on a PDN basis even for messages impacting only one 
bearer (i.e. Create Bearer Request). See 3GPP TS 23.007 [17] for further details on the CSID and what specific 
requirements are placed on the PGW, SGW and MME. 

8.63 Channel needed 

The Channel needed shall be coded as depicted in Figure 8.63-1. Channel needed is coded as the lEI part and the value 
part of the Channel Needed IE defined in 3GPP TS 44.0 18 [28] 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 133 (decimal) 




Length = n 


Spare Instance 


Channel Needed 



Figure 8.63-1 : Channel needed 
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8.64 eMLPP Priority 



The eMLPP-Priority shall be coded as depicted in Figure 8.64-1. The eMLPP Priority is coded as the value part of the 
eMLPP-Priority IE defined in 3GPP TS 48.008 [29] (not including 3GPP TS 48.008 lEI and 3GPP TS 48.008 [29] 
length indicator). 



Octets 

1 

2 to 3 

4 

5 to (rn-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 134 (decimal) 




Length = n 


Spare Instance 


eMLPP-Priority 



Figure 8.64-1 : eMLPP Priority 



8.65 Node Type 

Node Type is coded as this is depicted in Figure 8.65-1. 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 135 (decimal) 




Length = 1 (decimal) 


Spare Instance 


Node Type 


6-(n-^4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.65-1 : Node Type 

Node type values are specified in Table 8.65-1. 

Table 8. 65-1 : Node Type values 



Node Types 


Values (Decimal) 


MME 





SGSN 


1 


<spare> 


2-255 



8.66 Fully Qualified Domain Name (FQDN) 

Fully Qualified Domain Name (FQDN) is coded as depicted in Figure 8.66-1. 



Octets 

1 

2 to 3 

4 

5 to (n-i-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 136 (decimal) 




Length = n 


Spare Instance 


FQDN 



Figure 8.66-1 : Fully Qualified Domain Name (FQDN) 

The FQDN field encoding shall be identical to the encoding of a FQDN within a DNS message of section 3. 1 of IETF 
RFC 1035 [31] but excluding the trailing zero byte. 

NOTE 1: The FQDN field in the IE is not encoded as a dotted string as commonly used in DNS master zone files. 

A "PGW node name" IE in S3/S10/S16 GTP messages shall be a PGW host name as per subclause 4.3.2 of 3GPP TS 
29.303 [32] when the PGW FQDN IE is populated from 3GPP TS 29.303 [32] procedures. Specifically, the first DNS 
label is either "topon" or "topoff , and the canonical node name of the PGW starts at the third label. The same rules 
apply to "SGW node name" IE on S3/S10/S16. 
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NOTE 2: The constraint of subclause 4.3.2 of 3GPP TS 29.303 format is on populating the IE by 3GPP nodes for 
3GPP nodes, the receiver shall not reject an IE that is otherwise correctly formatted since the IE might be 
populated for a non-3GPP node. 

8.67 Private Extension 

Private Extension is coded as depicted in Figure S.Figure 8.67-1. 

Enterprise ID can be found at lANA web site ( http ://w w w . iana. org/as signments/enterprise-numbers ) . 



Octets 

1 
2 to 3 

4 

5 to 6 

7 to {n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 255 (decimal) 




Length = n 


Spare Instance 


Enterprise ID 


Proprietary value 



Figure 8.67-1. Private Extension 



8.68 Transaction Identifier (Tl) 



Transaction Identifier is coded as depicted in Figure 8.68-1. It is defined in 3GPP TS 24.301 [23], clause 9.9.4.17 and is 
coded as specified in 3GPP TS 24.007 [30], clause 1 1.2.3.1.3 Transaction identifier. 



Octets 

1 

2 to 3 

4 

5 to (n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 137 (decimal) 




Length = n 


Spare Instance 


Transaction Identifier 



Figure 8.68-1 : Transaction Identifier 



8.69 RFSP Index 



Index to RAT/Frequency Selection Priority (RFSP Index) is coded as depicted in Figure 8.69-1. It is defined in 3GPP 
TS 36.413 [10] as Subscriber Profile ID for RAT/Frequency priority (SPIRFP). The SPIRFP is an integer between 1 
and 256, which requires two octets. 



Octets 

1 
2 to 3 

4 
5 to 6 


Bits 
8 7 6 5 4 3 2 


1 




Type = 144 (decimal) 




Length = 2 


Spare Instance 


RFSP Index 



Figure 8.69-1. RFSP Index 



8.70 Service indicator 

Service indicator is coded as depicted in Figure 8.70-1. 



Octets 

1 

2 to 3 

4 

5 


Bits 
8 7 6 5 4 3 2 


1 




Type = 149 (decimal) 




Length = 1 


Spare Instance 


Service indicator 



Figure 8.70-1. Service indicator 
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Service indicator values are specified in Table 8.70-1. 

Table 8. 70-1 : Service indicator values 



Service indicator 


Values (Decimal) 


<spare> 





CS call indicator 


1 


SMS indicator 


2 


<spare> 


3-255 



8.71 Detach Type 

Detach Type is coded as depicted in Figure 8.71-1. 



Octets 

1 

2 to 3 

4 

5 


Bits 
8 7 6 5 4 3 2 


1 




Type = 150 (decimal) 




Length = 1 


Spare Instance 


Detach Type 



Figure 8.71-1 : Detach Type 
Table 8.71-1 : Detach Type values 



Detach Types 


Values (Decimal) 


<reserved> 





PS Detach 


1 


Combined PS/CS Detach 


2 


<spare> 


3-255 



Security 



GTPv2-C communications shall be protected according to security mechanisms defined in 3GPP TS 33.401 [12]. 



10 IP - The Networking Technology used by GTP 
10.1 IP Version 

GTPv2 entities shall support both versions of the Internet Protocol, version 4 (IPv4) as defined by IETF RFC 791 [6], 
and version 6 (IPv6) as defined by IETF RFC 2460 [16]. 



10.2 IP Fragmentation 



It is specified here how the fragmentation mechanism shall work with GTP-C. 

Fragmentation should be avoided if possible. Examples of fragmentation drawbacks are: 

Fragmentation is inefficient, since the complete IP header is duplicated in each fragment. 

If one fragment is lost, the complete packet has to be discarded. The reason is that no selective retransmission of 
fragments is possible. 
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Path MTU discovery should be used, especially if GTPv2-C message is encapsulated with IPv6 header. The application 
should find out the path MTU, and thereby utilise more efficient fragmentation mechanisms. 
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Annex A (Informative): 

Backward Compatibility Guidelines for Information Elements 

In order to preserve backward compatibility, the following rules should apply when adding or modifying information 
elements for existing messages. 

No new mandatory (M) information elements should be added. 

No new conditional (C) information elements should be added. 

Any new lEs should be either: 

optional (O), having no conditions on their presence, or 

conditional-optional (CO), having conditions that should apply only to the sender and not to the receiver. 

Such conditions should be worded generally as follows: "This IE shall be sent over the xxx interface 
<condition>. The receiving entity need not check the lE's presence." 

If any new conditions are added to a previously specified conditional (C) information element, these new 
conditions should apply only to the sender and not to the receiver. 

Such additional conditions should be worded generally as follows: "This IE shall be sent over the xxx interface 
<condition>. For this optional condition, the receiving entity need not check the lE's presence." 

Existing conditions for such conditional (C) lEs should be treated as before, and the presence of the lEs should 
remain conditional (C). 
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Annex B (informative): 
Change History 



Date 


TSG# 


TSG Doc 


CT4 Doc 


CR 


Rev 


Cat 


Subject/Comment 


Old 


New 


2008-12 


CT#42 


CP-080717 










V2.0.0 approved in CT#42 


2.0.0 


8.0.0 


2009-03 


CT#43 


CP-090050 


C4-090922 


0001 


2 


c 


Delete Indirect Data Forwarding Tunnel 
Request/Response 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090520 


0003 


1 


c 


Relocation Cancel Req/Res 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090834 


0004 


2 


c 


Path Failure 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090878 


0005 


4 


F 


Sections 1 through 6 Editorial Clean-up 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090879 


0006 


2 


c 


Delete Session and Delete Bearer messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090902 


0008 


2 


c 


Update User Plane messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090880 


0017 


2 


B 


Cleanup in path management and bearer 
command messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090526 


0018 


1 


C 


Create Session/Bearer IVlessages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090901 


0019 


2 


C 


Modify Bearer messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090991 


0020 


2 


C 


IBs in CSFB related messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090570 


0021 


1 


c 


Command Messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090939 


0022 


3 


c 


Data Forwarding Info 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090970 


0023 


3 


c 


Delete Bearer messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090941 


0024 


2 


c 


Delete Session messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090574 


0025 


1 


F 


Downlink Data Notification 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090942 


0026 


2 


F 


Update Bearer messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090952 


0027 


2 


c 


Secondary PDP Activation 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090874 


0028 


2 


c 


Stop Paging 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090577 


0030 


1 


F 


EPS Bearer Contexts Prioritization 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090875 


0032 


2 


F 


Linked EPS Bearer ID 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090578 


0034 


1 


F 


AMBR IE encoding 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090157 


0035 


- 


F 


Authentication Failure Cause Code 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090580 


0040 


1 


F 


Forward SRNS Context Notification 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090581 


0041 


1 


F 


F-TEID IE clarification 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090214 


. 


0043 


4 


F 


SGW Selection during TAU and corrections to 
Grouped lEs 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090583 


0043 


1 


F 


Identification Response algorithm information 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090798 


0044 


2 


F 


IE Type ordering 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090945 


0045 


2 


F 


Indication IE corrections 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090588 


0048 


1 


F 


MM Context enhancements 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090590 


0050 


1 


F 


Removal of Bearer ID List IE 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090591 


0051 


1 


F 


Remove unused IP Address lEs 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090592 


0052 


1 


F 


Selection Mode bits 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090593 


0053 


1 


F 


Corrections to Trace Information IE 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090946 


0054 


2 


F 


Trace Information IE to be included in S1 1 and 
S5/S8 messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090947 


0055 


3 


F 


Trace Session Activation/Deactivation when 
UE is attached 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090691 


0059 


1 


B 


New UE Time Zone IE Type 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090692 


0060 


1 


C 


Release Access Bearers Request/Response 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090256 


C4-090935 


0061 


3 


B 


Piggybacking of Dedicated Bearer Messages 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090933 


0063 


4 


C 


Finalizing GTPv2 Error Handling clause 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090598 


0064 


1 


F 


GTPv2 clause 9 and 10 cleanup 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090977 


0066 


4 


B 


RAN Information Relay message 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090975 


0067 


2 


F 


Bearer QoS encoding 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090694 


0068 


1 


F 


Modify Bearer Response 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090932 


0075 


3 


C 


Location Change Reporting 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090976 


0077 


2 


F 


Cleanup on Cause Values 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-09081 1 


0080 


1 


F 


Non-3GPP Requests in GTPv2 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090938 


0082 


3 


F 


Support of IP address retrieval for ANRF 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090814 


0083 


1 


F 


Support for error response for conflicting 
resource request 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090817 


0085 


1 


F 


Clarification of Target ID vs Cell ID 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090936 


0089 


2 


F 


TEID Value of the GTP header 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090826 


0093 


3 


B 


Header for the Format of the GTPv2-C 
message 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090871 


0094 


3 


C 


Finalization of Partial fault handling in GTPv2 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090822 


0095 


1 


F 


MSISDN encoding 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090823 


0096 


1 


F 


IMSI encoding 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090829 


0097 


1 


C 


PMIP error code reservation 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090549 


0098 




F 


Removal of Comprehension Required from 
messages 7.3.1 to 7.3.13 


8.0.0 


8.1.0 
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CT4 Doc 


CR 
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Cat 


Subject/Comment 


Old 


New 


2009-03 


CT#43 


CP-090050 


C4-090550 


0099 




F 


Cause value for PGW not responding 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090551 


0100 


- 


F 


Traffic Aggregate Description IE encoding 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090980 


0101 


3 


F 


Protocol Stack 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090831 


0102 


1 


C 


Reliable delivery for EPC 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090050 


C4-090915 


0104 




F 


Removal of reservation for message types of 
GTP-U 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090239 


- 


0105 


1 


F 


Essential correction to grouped IE type coding 


8.0.0 


8.1.0 


2009-03 


- 


- 


- 


- 


- 


- 


Some of the table formats corrected 


8.1.0 


8.1.1 


2009-06 


CT#44 


CP-090288 


C4-091020 


0107 




F 


Suspend and Resume are also used for 
IxRTTCS Fallback 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091459 


0108 




F 


Support for new cause code of "Unable to 
page UE due to CSFB" in Downlink Data 
Notification Acknowledgement. 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091460 


0109 




F 


Corrections on GTPv2 for 1x IWS IP address 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091461 


0110 




F 


Clarification of Operation Indication (01) 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091463 


0111 




F 


Usage of User Location Information (ULI) IE 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091465 


0112 




F 


PGW S5/S8 IP Address in Context Response 
message 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091471 


0114 




F 


Delete Indirect Data Forwarding Tunnel 
Response 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091537 


0115 


2 


F 


Error_Handling. Withdrawn 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091473 


0117 




F 


PCO Extensions added to messages 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091474 


0118 




F 


Clarifications to message directions 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091103 


0119 




F 


Removal of specification drafting hints 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091475 


0120 




F 


ISR related alignments 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091476 


0122 




F 


Clarifications to grouped IE usage 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091586 


0125 


2 


F 


Clarification to Recovery IE type 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091478 


0127 




F 


Missing conditions 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091480 


0128 




F 


Clarification of ARP encoding 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091115 


0129 


- 


F 


Units for APN-AMBR 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091481 


0131 


2 


F 


Clarification of Mobile Equipment Identity IE 
encoding 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091120 


0134 


- 


F 


EPS Bearer Level TFT encoding 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091587 


0136 


2 


F 


UE-initiated procedures with one bearer only 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091510 


0137 


2 


F 


Combine UL and DL TFT lEs 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091512 


0142 


1 


F 


PGW S5/S8 IP Address and TEID for user 
plane 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091513 


0143 


1 


F 


Transaction Identifier information element 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091515 


0147 


1 


F 


Delete Bearer Request 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091516 


0149 


2 


F 


Modify Bearer Request for TAU without MME 
or SGW change 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091538 


0150 


2 


F 


Use of APN, PAA in Create Session Request, 
and S5/S8-U PGW F-TEID in Create Session 
Response 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091540 


0151 


1 


F 


Message table corrections 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091162 


0153 


- 


F 


Presence requirement for lEs in response 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091537 


0154 


2 


F 


Offending IE in the Cause IE 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091541 


0156 


1 


F 


Minor corrections 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091542 


0157 


1 


F 


FQ-CSID corrections 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091167 


0158 


- 


F 


APN and FODN encoding clarifications 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091168 


0159 




F 


Removal of Trace Information IE from Update 
Bearer Request 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091467 


0160 


1 


F 


Corrections in PDN Connection group IE 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091543 


0161 


1 


F 


Missing lEs in "Update Bearer Response" 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091548 


0164 


2 


F 


PDN Type 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091549 


0168 


1 


F 


IE corrections in Modify Bearer signalling 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091550 


0169 


2 


F 


Create Session Request Clarification 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091202 


0175 


- 


F 


TEID in Detach Notification/ACK 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091203 


0176 




F 


Condition of bearer context in Modify Bearer 
messages 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091544 


0177 


1 


F 


Delete Session Request granularity 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091205 


0178 




F 


Deletion of IMSI in the Update Bearer Request 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091546 


0180 


1 


F 


Delete Session Request/Response and Delete 
Bearer Request 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091551 


0181 


1 


F 


Detach Notification 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091234 


0183 


- 


F 


SGSN Info for Data Forwarding 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091462 


0184 


1 


F 


Delete Session Request 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091561 


0185 


1 


F 


APN AMBR clarification 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091552 


0186 


1 


F 


Delete Bearer Request when ISR activated 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091553 


0187 


1 


F 


Clarify the usage of the MS validated IE 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091557 


0189 


1 


F 


UDP Source port and IP Source Address 


8.1.1 


8.2.0 
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Cat 
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Old 


New 


2009-06 


CT#44 


CP-090288 


C4-091241 


0190 




F 


Recovery IE 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091539 


0192 


1 


F 


APN Information 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090500 


- 


0193 


3 


F 


Cause value 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091547 


0195 


1 


F 


Cleanup indication 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091556 


0196 


1 


F 


Cleanup the usage of some messages 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091545 


0198 


1 


F 


Linked EPS Bearer ID 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091514 


0199 


1 


F 


PCO parameter 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091558 


0200 


1 


F 


PDP Context Activation 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091464 


0201 


1 


F 


User Location Info 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091559 


0202 


2 


F 


F-Cause IE correction 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090288 


C4-091560 


0206 


1 


F 


Message granularity 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090321 


. 


0209 




F 


Bearer Context in the Modify Bearer 
Command 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090493 


- 


0210 


1 


F 


Sequence Number Extension 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090355 


- 


0212 


- 


F 


Bearer Resource Command clarification 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090485 


- 


0213 


1 


F 


Piggybacked message clarifications 


8.1.1 


8.2.0 


2009-06 


CT#44 


CP-090472 


. 


0214 


1 


F 


Corrections on handling Charging ID IE and 
Charging Characteristics IE 


8.1.1 


8.2.0 


2009-09 


CT#45 


CP-090533 


C4-091625 


0215 




F 


Usage of GTPv2-C Header 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092004 


0216 


1 


F 


Create Session Request and Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092005 


0217 


1 


F 


Cleanup Editors Note 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092008 


0218 


1 


F 


Message format and Type values 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-091630 


0220 




F 


SI 6 Influence 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092012 


0222 


1 


F 


MM Context 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-091633 


0223 


- 


F 


F-Container 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-091635 


0225 




F 


Change Reporting Action 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092013 


0226 


1 


F 


Procedure names 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092134 


0228 


3 


F 


Changes to Create-Session-Request and 
Create-Session-Response messages 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092017 


0229 


1 


F 


Changes to Modify-Bearer-Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092014 


0232 


2 


F 


Piggybacking Clarifications 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092018 


0236 


1 


F 


Delete Bearer Request Cause value for ISR 
deactivation 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092019 


0237 


2 


F 


Modify Bearer Request Bearer Level QoS 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092020 


0239 


1 


F 


Possible reject response Cause values in 
GTPv2 message descriptions 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092002 


0241 


1 


F 


SGW F-TEID for SI -U, SI 2 and S4 for User 
Plane 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092103 


0243 


2 


F 


Clarification on the usage of Version Not 
Supported Indication 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092074 


0244 


1 


F 


Clarifications on Sender-F-TEID for CP and 
S3/S10/S16 CP IP Addr and TEID lEs 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092076 


0245 


1 


F 


Cause Value in Echo Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-091722 


0246 




F 


Corrections in ULI IE and PDN Connection IE 
definitions 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092656 


0247 


3 


F 


GTPv2 Initial and Triggered Message 
definition and Sequence Number handling 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092078 


0249 


1 


F 


Missing Cause values in some message 
descriptions 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-09271 1 


0250 


4 


F 


Add TAC to Target Identification IE 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090533 


C4-092081 


0256 


1 


F 


IMSI and Sender F-TEID in Create Indirect 
Data Forwarding Tunnel Messages 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092009 


0258 


1 


F 


Indication in Forward Relocation messages 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092082 


0259 


1 


F 


Paging cause 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-091784 


0260 


. 


F 


Correlate the bearers in the Create Bearer 
Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092651 


0261 


3 


F 


Cleanup cause values 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092104 


0262 


2 


F 


Delete Bearer Failure Indication 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092083 


0263 


1 


F 


Cleanup Modify Bearer Request 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092085 


0264 


2 


F 


lEs in Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-091790 


0266 


- 


F 


CS Paging Indication 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092086 


0267 


2 


F 


Serving Network 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092636 


0268 


3 


F 


Service Handover support 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092105 


0269 


3 


F 


Fix incorrect interface name, incorrect 
reference and other misreading texts 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092106 


0270 


1 


F 


Clarification on cause value for Downlink Data 
Notification Failure Indication 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092710 


0271 


2 


F 


Clarification on the Authentication Vector 
handling 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092043 


0276 


1 


F 


Clarification on Authentication Vector encoding 


8.2.0 


8.3.0 
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Old 


New 


2009-09 


CT#45 


CP-090535 


C4-092751 


0278 


5 


F 


Clarification on Error indication for EPC and 
DT 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092112 


0279 


3 


F 


Aligning IVIBR units to l<bps 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092108 


0281 


1 


F 


Clarification to the PGW's UP address in 
Create Session Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092686 


0282 


4 


F 


Modify Bearer procedure for X2 and SI based 
handovers 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092109 


0290 


1 


F 


Add necessary cause value to the Update 
Bearer Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092000 


0292 




F 


Update on Concurrent Running of Security 
Procedures 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092642 


0295 


2 


F 


APN Restriction IE 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092644 


0296 


1 


F 


Change Reporting IE 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092646 


0297 


1 


F 


ULI Clarification 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092189 


0301 


- 


F 


Charging ID 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090534 


C4-092647 


0302 


1 


F 


Delete Indirect Data Forwarding Tunnel 
Request/Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092648 


0303 


1 


F 


SGW F-TEID 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092649 


0304 


1 


F 


BCM 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092652 


0307 


3 


F 


Charging Gateway Address 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092653 


0308 


1 


F 


LBI Clarifications for Gn/Gp Handovers 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092654 


0309 


1 


F 


Trace management messages and IE related 
clarifications 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092655 


0310 


1 


F 


Indirect Data Forwarding Tunnel clarifications 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092635 


0311 


2 


F 


Concurrent Running of Security Procedures 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092657 


0315 


1 


F 


Cause value corrections 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092659 


0316 


1 


F 


Identification Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092677 


0317 


1 


F 


NSAPI and EBI in Forward Relocation 
Response 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092678 


0318 


1 


F 


Cause in the CSFB related messages 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092650 


0320 


1 


F 


Update Bearer Complete 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092679 


0321 


1 


F 


PCOIE 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092368 


0322 


- 


F 


Cleanup Trace Management messages 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092369 


0323 


- 


F 


Cleanup section 5.3 and 8.12 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092680 


0324 


1 


F 


APN AMBR in the Create Bearer Request 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092681 


0325 


1 


F 


UDP Source Port Number 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092372 


0326 


- 


F 


Presence Requirments for grouped IE 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092709 


0330 


1 


F 


Making PCO conditional for the Attach 
procedure 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092388 


0332 




F 


Echo usage alignment with stage 2 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092397 


0334 




F 


Trace Depth per session 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092740 


0335 


4 


F 


Backward compatibility requirements for 
presence 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092712 


0338 


1 


F 


ECGI encoding correction 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092713 


0339 


1 


F 


Consistant PDN type setting 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092714 


0340 


1 


F 


GTP Cause value usage 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090729 


C4-092626 


0341 


1 


F 


Partial failure handling alignment with stage 2 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090729 


C4-092738 


0342 


2 


F 


Partial failure handling for MME relocation w/o 
SGW relocation 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092634 


0346 


1 


F 


Security Specification for GTPV2-C 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092715 


0349 


1 


F 


Avoiding Source Port Overlap between 
GTPV2-C and GTPv2-C' 


8.2.0 


8.3.0 


2009-09 


CT#45 


CP-090535 


C4-092478 


0350 




F 


Delete Bearer Command PCO removal 


8.2.0 


8.3.0 


2009-10 














Editorial correction. Wrong style was used in 
Paragraph character 7.1 .3. 


8.3.0 


8.3.1 


2009-12 


CT#46 


CP-090769 


C4-093159 


0355 


1 


F 


Selection Mode IE 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-092829 


0358 




F 


Bearer OoS in Modify Bearer Reques 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-093704 


0360 


1 


F 


Release Access Bearer Request 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-092833 


0362 




F 


Bearer context in Create Session messages 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-092856 


0364 




F 


ISRAI flag in the Forward Relocation Complete 
Notification 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-092860 


0368 




F 


Mapping between RAI, P-TMSI, P-TMSI 
signature and GUTI 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093328 


0370 


1 


F 


APN IE encoding 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093330 


0372 


1 


F 


Correction on the condition for resource 
release of other CN node 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090969 


- 


0374 


2 


F 


APN Restriction 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093334 


0376 


1 


F 


Cause value "Invalid reply from remote peer" 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093336 


0379 


1 


F 


Indication Flags in Delete Session Request 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093338 


0381 


1 


F 


Suspend 


8.3.1 


8.4.0 
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New 


2009-12 


CT#46 


CP-090770 


C4-092892 


0385 






Removal of forwarding Cfiarging Gateway 
Address/Name to S4-SGSN 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093263 


0387 


2 




Charging ID in S4-SGSN 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-092898 


0389 






Correction of Message Direction for Create 
Session Response 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093344 


0391 


1 




PPC (Prohibit Payload Compression) 
alignment with Stage-2 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093277 


0396 


3 




User Location Information 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094050 


0398 


2 




PDN type 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093003 


0402 






Removal of ULI from Release Access Bearer 
Req 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093005 


0404 






Removal of NSAPI IE 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093269 


0406 


2 




Indication IE clarification 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093261 


0408 


3 




Addition of uplink, downlink F-TEIDs in Create 
Indirect Data Forwarding Tunnel Request and 
Response messages 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093350 


0410 


2 




Clarifications on use of the Sender-F-TEID for 
CP in HO procedure 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093033 


0416 






Clarifications to MSISDN coding 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094037 


0418 


2 




Enhanced handling of RFSP index at the 
SGSN/MME 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094039 


0422 


2 




TFT related error handling 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094035 


0424 


4 




Essential correction to the Indirect Data 
Forwarding procedure 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-093396 


0430 


1 




UE TimeZone and ULI included in Bearer 
Response messages 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094041 


0433 


1 




Correcting misaligned IE presence type 
statements 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094043 


0437 


1 




Correcting PCO conditions in Modify Bearer 
Response 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094183 


0441 


2 




Delete Indirect Data Forwarding Tunnel 
messages 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090/// 


C4-09407e 


0447 


1 




SRVCC - voice bearer handling in PS HO / 
DTM scenario 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-091024 




0449 


3 




NAS Count value 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094048 


0451 


1 




Charging Characteristics value for active PDN 
connection 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-093646 


0454 






Change the NSAPI to EBI in the PFI IE 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-093648 


0456 






Enhanced SRNS Relocation Procedure 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-093650 


0458 






Forward Access Context Acknowledge 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-093667 


0460 






Correct the message Modify Bearer Request 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-094058 


0470 


1 




Cleanup Suspend Notification message 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090769 


C4-093827 


0474 






Forward Relocation Request: Selected PLMN 
ID 


8.3.1 


8.4.0 


2009-12 


CT#46 


CP-090770 


C4-094073 


0485 






Change Reporting Action 


8.3.1 


8.4.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00766 


0492 


1 




Essential clarification to MME executed TAU 
procedure 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00971 


0494 


5 




Essential correction to the MM context IE type 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00775 


0496 


1 




Resolving ambiguity for Target Identification IE 
coding 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00777 


0500 


1 




Trace alignment with TS 32.422 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00275 


0503 






PCO 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00787 


0505 


1 




RFSP Index 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-100019 


C4-100317 


0511 






The encoding of APN IE 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00792 


0513 


1 




Indirect Data Forwarding 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00799 


0515 


1 




HSS/PGW initiated Bearer OoS Modification 
procedure 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00855 


0517 


1 




APN IE description correction 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00959 


0519 


2 




P-TMSI Signature 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00395 


0522 






Source Identification for E-UTRAN to GERAN 
handover 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00865 


0531 


1 




Granularity 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-100719 


0532 


2 




Change Reporting Support Indicator 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-100415 


0534 






MM Context IE type correction 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00027 


C4-1 00991 


0536 


2 




Removal of TElDs for PS voice bearer UP in 
Bearer Context for SRVCC 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-100419 


0538 






Correction on the presence condition of 
Charging ID IE on S4 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00875 


0547 


1 




Modify Octets Sequence Number of RAB 
Context IE 


8.4.0 


8.5.0 
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CR 


Rev 


Cat 


Subject/Comment 


Old 


New 


2010-03 


CT#47 


CP-1 00022 


C4-1 00877 


0549 


1 


F 


Revive the cause value "User Authentication 
Failed" in the Create Session Response 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00973 


0555 


2 


F 


Fix PDN Connection Grouped Type 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00975 


0557 


2 


F 


Correction on the down link notification failure 
procedure 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00978 


0564 


2 


F 


Correction of the presence condtion of lEs 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00783 


0566 


1 


F 


Figure number, Information element and 
message usage 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00980 


0568 


2 


F 


2G related parameters in the Forward 
Relocation Request and Context Response 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00982 


0576 


2 


F 


Essential correction to the Create Bearer 
Request message 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00905 


0580 


1 


F 


Essential correction to the FTEID IE 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-1 00990 


0582 


3 


F 


Essential correction to Modify Bearer Request 
for non-3GPP to 3GPP handover 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00021 


C4-1 00600 


0584 




F 


Removal of unncessary cause 'Unexpected 
repeated IE' 


8.4.0 


8.5.0 


2010-03 


CT#47 


CP-1 00022 


C4-100912 


0586 


1 


F 


Removal of indirect uplink data forwarding 
from Inter RAT handovers 


8.4.0 


8.5.0 


2010-06 


CT#48 


CP-1 00266 


C4-101478 


0598 


1 


F 


Essential corrections to M-TMSI mapping 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101579 


0602 


3 


F 


Change Notification 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101119 


0604 




F 


Fix missing conditional description for lEs in 
the context response message 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101485 


0613 


1 


F 


Change Reporting Support Indication 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101488 


0617 


1 


F 


Handover/Relocation cancel procedure 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101490 


0623 


1 


F 


ULI in the Modify Bearer Request message 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101494 


0625 


1 


F 


MM context IE encoding 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101582 


0634 


2 


F 


MBR in handover from non-3GPP to 3GPP 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101192 


0636 




F 


Suspend over SI 6 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101503 


0641 


1 


F 


Adding Service indicator to CS Paging 
Indication 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101598 


0647 


3 


F 


Fallback to GTPvl 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101552 


0649 


2 


F 


Essential correction to ULI IE condition in 
Modify Bearer Request message 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101554 


0656 


1 


F 


TEID in Change Notification 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101557 


0658 


1 


F 


Charging ID 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101290 


0663 




F 


Alert MME Notification / UE Activity 
Notification procedure on S3 interface 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00266 


C4-101600 


0677 


1 


F 


Handling of Create Session Request message 
on TEID for existing PDN connection 


8.5.0 


8.6.0 


2010-06 


CT#48 


CP-1 00297 


. 


0679 




F 


Essential correction for the Initial Attach 
procedure 


8.5.0 


8.6.0 


2010-09 


CT#49 


CP-1 00445 


C4-101920 


0629 


4 


F 


IP Address IE clarification 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-101677 


0684 




F 


Originating Node 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-101875 


0686 


1 


F 


Condition of ISRAI Flag 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-101877 


0688 


1 


F 


PDN Connection for Subscription Data 
Change 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00445 


C4-101883 


0704 


1 


F 


Cause value in Detach Notification 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00445 


C4-101885 


0706 


1 


F 


SI based handover cancel 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00445 


C4-101903 


0708 


1 


F 


Used NAS integrity protection algorithm values 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00445 


C4-101890 


0717 


1 


F 


Change Notification Response 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-1 02388 


0735 


2 


F 


Resume messages 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-102317 


0737 


1 


F 


LAI field 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-1 02325 


0739 


1 


F 


P-TMSI Signature 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-1 02328 


0747 


1 


F 


PDN Connection for Subscription Data 
Change 


8.6.0 


8.7.0 


2010-09 


CT#49 


CP-1 00444 


C4-1 02330 


0749 


1 


F 


E-UTRAN to HRPD handover 


8.6.0 


8.7.0 


2010-12 


CT#50 


CP-1 00672 


C4-1 03290 


0849 


1 


F 


Determination of type of source node during 
TAU/RAU 


8.7.0 


8.8.0 


2010-12 


CT#50 


CP-1 00674 


C4-1 02773 


0763 


1 


F 


Essential correction to Create Indirect Data 
Forwarding Tunnel Response 


8.7.0 


8.8.0 


2010-12 


CT#50 


CP-1 00667 


C4-1 02968 


0826 




F 


UE Time Zone adjustments 


8.7.0 


8.8.0 


2010-12 


CT#50 


CP-1 00669 


C4-1 03338 


0814 


2 


F 


Essential alignment with PMIP spec 


8.7.0 


8.8.0 


2011-03 


CT#51 


CP-1 10042 


C4-1 10363 


0890 




F 


Correcting IE Type for Bearer QoS IE from 
Variable to Extendable 


8.8.0 


8.9.0 


2011-03 


CT#51 


CP-1 10042 


C4-1 10977 


0912 


1 


F 


Essential correction to the encoding of Target 
RNC-ID 


8.8.0 


8.9.0 


2011-06 


CT#52 


CP-1 10355 


C4-111627 


0925 


2 


F 


Mapping of ASN.1/PER parameters to GTPv2 
lEs 


8.9.0 


8.10.0 


2011-06 


CT#52 


CP-1 10355 


C4-111549 


0962 


1 


F 
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